Integrar ServiceNow con IA: guía práctica para pilotos reales

Sin categoría

La forma más rápida y controlada de integrar IA en ServiceNow es desplegar agentes sobre ServiceNow AI Platform y conectar tus sistemas mediante Integration Hub con radios (spokes), validando gobernanza y calidad de datos antes de lanzar cualquier piloto. Este patrón evita dos errores comunes: construir integraciones a medida cuando ya existe un conector certificado, y activar un agente conversacional sin haber definido quién audita sus decisiones.

Antes de tocar una sola línea de configuración, necesitas resolver tres cosas. Primero, las licencias correctas de AI Platform y los plugins de Integration Hub que tu instancia requiere. Segundo, acceso limpio a los datos que el agente va a consultar, con roles y permisos ya definidos. Tercero, un acuerdo explícito con el área de negocio sobre qué mide el éxito del piloto.

Los resultados de un piloto bien planteado suelen ser medibles en semanas, no meses:

Tasa de resolución autónoma alta en flujos bien acotados (clasificación de tickets, consultas frecuentes, agendamiento).
Reducción visible del volumen de tickets escalados a soporte humano.
Tiempos de respuesta iniciales que bajan de horas a segundos en los canales conectados.

Consejo profesional: no empieces por el caso más complejo de tu operación. Elige un flujo con reglas claras y bajo riesgo regulatorio: ahí es donde un piloto de 2 a 4 semanas puede demostrar valor sin comprometer procesos críticos.

En resumen:

Para acelerar la integración, es recomendable desplegar agentes sobre ServiceNow AI Platform y conectar sistemas mediante Integration Hub, priorizando radios predefinidos.

Es imprescindible resolver previamente licencias, permisos de datos y criterios de éxito con negocio para evitar retrasos en el piloto.

La conectividad debe seguir un orden: usar primero conector certificado, luego generador OpenAPI y, si no existe, tablas remotas, para controlar costos y mantenimiento.

La gobernanza centralizada a través de la Torre de control de IA asegura visibilidad y trazabilidad de decisiones, fundamental para la escalabilidad del proyecto.

Un piloto bien definido y ajustado en semanas, con flujo claro y pruebas controladas, incrementa significativamente las probabilidades de éxito y escalamiento.

Tabla de contenidos

Qué es ServiceNow AI Platform y qué componentes importan para integrar IA
¿Cómo conectar sistemas externos con Integration Hub?
¿Cómo se orquestan los agentes de IA en ServiceNow?
Prerrequisitos técnicos y de negocio antes de integrar
Pasos prácticos para pasar de la idea al piloto
Seguridad, privacidad y gobernanza de modelos
Casos de uso frecuentes y qué métricas medirlos
Experiencia práctica: cómo lo hacemos en Anunzi
Checklist técnico para el equipo de implementación
La lección que la mayoría de los proyectos aprende demasiado tarde
Cómo Anunzi acelera la integración de agentes de IA con ServiceNow
Puntos clave
Fuentes
Preguntas frecuentes

Qué es ServiceNow AI Platform y qué componentes importan para integrar IA

ServiceNow describe su plataforma como un «sistema de acción»: un entorno donde la inteligencia artificial no solo sugiere, sino que ejecuta tareas con el contexto completo del negocio, porque IA, datos, flujos de trabajo y seguridad viven en la misma arquitectura unificada. Esa integración nativa es la diferencia real frente a conectar un modelo de lenguaje suelto a un sistema de tickets: el agente entiende qué es un cliente, qué es un incidente y qué reglas de negocio aplican, sin que tengas que reconstruir ese contexto en cada llamada a la IA.

Tres piezas sostienen esa arquitectura cuando planeas una integración:

Torre de control de IA: el punto central donde se gobiernan modelos, agentes y políticas de uso en toda la organización, en lugar de dejar que cada equipo despliegue IA por su cuenta.
Workflow Data Fabric: el tejido que conecta datos dispersos (CRM, ERP, sistemas de tickets) en un modelo único, para que el agente razone con información actualizada en vez de copias desfasadas.
Modelo de datos común: la base que permite que un agente de atención al cliente y otro de TI compartan la misma noción de «usuario», «caso» o «prioridad».

La Torre de control de IA es especialmente relevante para responsables de negocio, porque responde a la pregunta que casi siempre bloquea un piloto: ¿quién ve qué modelo está tomando qué decisión, y con qué datos? Sin esa visibilidad centralizada, cada área termina evaluando su propio agente con criterios distintos, y el proyecto pierde comparabilidad.

Para equipos técnicos, la ventaja práctica es que no hay que ensamblar esta arquitectura desde cero. AI Platform ya trae el andamiaje de gobernanza, el modelo de datos y el motor de agentes integrados, así que el trabajo de integración se concentra en dos frentes: conectar las fuentes externas que todavía no están en ServiceNow, y diseñar el comportamiento del agente sobre datos que ya existen dentro de la plataforma. Esa distinción determina cuánto esfuerzo real llevará el proyecto, y es el tema de la siguiente sección.

¿Cómo conectar sistemas externos con Integration Hub?

Integration Hub es el concentrador que resuelve la mayoría de las conexiones sin escribir integraciones desde cero. Ofrece radios predefinidos, un generador de radios basado en OpenAPI y tablas remotas para sistemas que no tienen conector certificado, cubriendo tanto aplicaciones modernas como entornos legacy. La decisión clave no es técnica en sí misma, es de secuencia: qué patrón usar primero y cuándo escalar al siguiente.

Empieza por los radios predefinidos. Si el sistema que quieres conectar (Salesforce, Microsoft Teams, un ERP común, una pasarela de pagos habitual) ya tiene un radio certificado, úsalo. Es la vía más rápida y la que menos mantenimiento exige a largo plazo.
Si no existe conector, evalúa el generador de radios con OpenAPI. Cuando el sistema externo publica una especificación OpenAPI, puedes generar un radio personalizado en horas en lugar de semanas, aprovechando plantillas ya probadas en Integration Hub.
Para sistemas sin API documentada, usa tablas remotas o activadores REST. Es la opción menos elegante pero más flexible: permite leer y escribir datos de sistemas legacy sin exigirles que expongan una API moderna.
Reserva el desarrollo a medida para el último escalón. Solo cuando ninguna de las tres opciones anteriores cubre el caso tiene sentido construir una integración completamente personalizada.

Este orden importa porque el coste de mantenimiento crece exponencialmente en cada escalón. Un radio predefinido lo actualiza y certifica ServiceNow; un radio personalizado generado por IA generativa lo mantienes tú, aunque el esfuerzo inicial sea bajo, evitando dependencias en integraciones preconstruidas cuando el sistema es propietario o muy particular. Las tablas remotas, por su parte, son prácticas para lecturas frecuentes pero pueden volverse lentas si el volumen de datos crece sin que optimices las consultas.

También conviene decidir de entrada qué modelo de lenguaje alimentará al agente. El controlador de IA generativa nativo de ServiceNow permite conectar modelos externos como Azure OpenAI, o usar el modelo propio de la plataforma, y esa elección reduce buena parte del scripting complejo que antes exigía integrar un LLM externo a mano. En la práctica, apoyarte en un LLM externo suele ser la vía más rápida para validar un piloto, mientras que el modelo nativo de ServiceNow aporta más control cuando la organización tiene requisitos estrictos sobre dónde viven los datos.

Consejo profesional: antes de generar un radio personalizado, revisa si el sistema objetivo tiene algún socio tecnológico que ya lo haya integrado. Empresas especializadas en automatización con IA suelen tener plantillas reutilizables para sistemas de nicho que te ahorran semanas de prueba y error.

¿Cómo se orquestan los agentes de IA en ServiceNow?

Un agente de IA en ServiceNow no es un chatbot aislado que responde preguntas sueltas. Se define en el estudio de agentes, donde describes su comportamiento en lenguaje natural (qué tareas puede resolver, qué herramientas tiene disponibles, cuándo debe derivar a un humano), y la plataforma traduce esas instrucciones en un flujo ejecutable conectado al modelo de datos.

La orquestación es lo que distingue una integración madura de una demo. Cuando una consulta requiere más de un agente (por ejemplo, uno que clasifica el incidente y otro que ejecuta la solución técnica), el orquestador central coordina esa secuencia. El protocolo Agent2Agent permite que agentes especializados se pasen tareas entre sí sin que el usuario perciba la transición, algo especialmente útil en escenarios donde un mismo caso cruza áreas: TI, RR. HH. y atención al cliente pueden compartir una misma conversación sin que el ciudadano o empleado tenga que repetir su problema tres veces.

Los canales donde vive esta experiencia varían según el caso de uso:

Voz: para atención ciudadana o soporte telefónico de primer nivel, donde la latencia y la naturalidad de la conversación importan más que la profundidad técnica.
Texto conversacional: integrado en portales de autoservicio o en aplicaciones de mensajería para consultas de TI o RR. HH.
Paneles Now Assist: donde agentes humanos reciben sugerencias y resúmenes generados por IA mientras trabajan un caso, sin que el agente actúe de forma autónoma.
APIs: para que sistemas externos (una app móvil, un portal de partners) invoquen directamente las capacidades del agente sin pasar por la interfaz nativa de ServiceNow.

La elección de canal no es cosmética. Un agente de voz para reclamaciones ciudadanas exige un diseño conversacional distinto al de un asistente que opera dentro de un panel interno para agentes de soporte, porque el primero interactúa con alguien que puede colgar en cualquier momento y el segundo trabaja dentro de un flujo ya supervisado por un humano. Diseñar ambos con el mismo guion es el error más común en proyectos que subestiman esta diferencia.

Prerrequisitos técnicos y de negocio antes de integrar

Casi todos los retrasos en proyectos de integración de IA en ServiceNow vienen de saltarse esta fase, no de problemas durante el desarrollo. Tres bloques de prerrequisitos determinan si el piloto arranca a tiempo o se estanca en aprobaciones.

Licencias y plugins habilitados. Confirma con tu representante de ServiceNow qué nivel de AI Platform cubre tu instancia y qué plugins de Integration Hub necesitas activar según los sistemas que vas a conectar. Activar un plugin a mitad de proyecto suele añadir días de espera que un checklist inicial evita.
Acceso y calidad de datos. Un agente entrenado sobre datos incompletos o desactualizados produce respuestas incorrectas con la misma confianza que respuestas correctas, lo cual es peor que no automatizar nada. Define qué tablas alimentan al agente, quién es propietario de esos datos y qué roles tienen permiso de lectura o escritura.
Alineamiento de negocio sobre objetivos. El área técnica y el área de negocio deben acordar, antes de escribir configuración alguna, qué métrica define el éxito: ¿tasa de resolución autónoma?, ¿reducción de tiempo medio de atención?, ¿volumen de casos derivados a humanos? Sin ese acuerdo previo, el piloto termina evaluado con criterios distintos por cada parte interesada.

El modelo de datos único de AI Platform reduce buena parte del segundo punto, porque evita que cada agente trabaje con una copia distinta de la información. Pero eso no exime al equipo de revisar la calidad de los datos de origen: un modelo de datos unificado no arregla un CRM con contactos duplicados o campos vacíos, solo garantiza que el agente vea la misma fuente que el resto de la plataforma.

Un piloto técnico bien diseñado necesita, además, un entorno de pruebas con datos anonimizados y una ventana representativa de tráfico real antes de pasar a producción. Sin esa validación previa, los primeros errores del agente los sufren usuarios reales, no un entorno controlado.

Pasos prácticos para pasar de la idea al piloto

Un roadmap realista para integrar IA en ServiceNow suele moverse en cinco fases, cada una con entregables verificables antes de avanzar a la siguiente.

Define el caso de uso y los KPI con los interesados. Reúne a TI, al área de negocio afectada y a quien apruebe el presupuesto en una misma sesión. Sal de ahí con un caso de uso concreto (clasificación de tickets de nivel 1, agendamiento de citas, gestión de reclamos) y dos o tres métricas medibles, no aspiraciones vagas de «mejorar la eficiencia».
Prepara el entorno. Confirma licencias de AI Platform, habilita los plugins de Integration Hub necesarios y monta un sandbox aislado de producción. Este es el momento de resolver accesos y permisos, no durante las pruebas.
Conecta las fuentes de datos. Aplica el orden de la sección anterior: radios predefinidos primero, generador de radios con OpenAPI si hace falta, tablas remotas como último recurso antes de un desarrollo a medida.
Diseña el flujo del agente. Define en el estudio de agentes qué preguntas puede resolver de forma autónoma, cuáles requieren confirmación humana y cuáles debe derivar sin intentarlo. Este es el paso donde se decide el equilibrio entre autonomía y control.
Ejecuta pruebas de seguridad, pruebas de usuario y despliegue controlado. Antes de abrir el agente a todo el volumen de tráfico, valida con un grupo reducido de usuarios reales y revisa los registros de decisiones que tomó el agente.

Dentro de esa quinta fase conviene aplicar una checklist de validación que muchos equipos técnicos pasan por alto porque asumen que «funciona en la demo» equivale a «funciona en producción»:

Verifica que cada decisión del agente quede registrada en un ticket con metadatos suficientes para auditoría posterior.
Confirma que el flujo de derivación a un humano funciona incluso cuando el agente falla a mitad de conversación, no solo al inicio.
Revisa los permisos de las credenciales que usa el agente para acceder a sistemas externos, evitando privilegios más amplios de los que la tarea requiere.
Mide la latencia real del flujo completo, no solo la respuesta del modelo de lenguaje, porque los radios y las llamadas a sistemas externos suman tiempo.
Documenta qué pasa si el sistema externo conectado por un radio deja de responder, y qué mensaje recibe el usuario en ese escenario.

Consejo profesional: diseña el agente para que degrade a un humano con contexto completo, no con un mensaje genérico de «no puedo ayudarte con eso». Registrar cada decisión del agente en el ticket, con la metadata de por qué escaló, es lo que después te permite reentrenar el flujo con casos reales en vez de suposiciones.

Una vez superada esta fase, el despliegue controlado suele extenderse entre dos y cuatro semanas antes de abrir el agente a todo el volumen de producción, dando tiempo suficiente para ajustar reglas de negocio sin comprometer la experiencia de usuarios reales desde el primer día.

Seguridad, privacidad y gobernanza de modelos

La Torre de control de IA existe precisamente para responder a la pregunta que todo comité de seguridad hace antes de aprobar un agente en producción: ¿qué modelo tomó esta decisión, con qué datos, y quién lo autorizó? Auditar esto no es un ejercicio puntual, es una práctica continua que debe quedar integrada en el flujo de trabajo desde el diseño.

Tres frentes concentran la mayoría del riesgo real en estos proyectos:

Gestión de credenciales y panel de conexiones. Cada radio y cada tabla remota usa credenciales que deben revisarse periódicamente. Un token con permisos de escritura que ya no se usa es una puerta abierta innecesaria.
Minimización de datos sensibles. El agente solo debería acceder a los campos que necesita para resolver la tarea, no a la tabla completa. Esto reduce el impacto de un eventual error de configuración.
Trazabilidad de decisiones. Cada acción autónoma del agente debe quedar registrada de forma que un auditor externo pueda reconstruir por qué el sistema actuó así, sin depender de la memoria del equipo técnico.

La gobernanza no es solo un requisito de cumplimiento. Es también lo que le da a los responsables de negocio la confianza para ampliar el alcance del agente después del piloto. Un proyecto que arranca sin trazabilidad clara tiende a quedarse estancado en su fase inicial porque nadie se anima a autorizar más autonomía sin poder explicar qué pasó en los casos anteriores.

Consejo profesional: revisa el panel de conexiones de Integration Hub al menos una vez al mes durante los primeros seis meses de operación. Es habitual que queden radios activos apuntando a credenciales de prueba que nadie desactivó tras pasar a producción.

Casos de uso frecuentes y qué métricas medirlos

Los flujos que mejor funcionan al integrar IA en ServiceNow comparten una característica: reglas de decisión claras y un volumen suficiente de casos repetitivos como para que la automatización tenga impacto medible.

Clasificación automática de tickets de TI. El agente lee la descripción del incidente, lo categoriza y lo asigna a la cola correcta, reduciendo el tiempo medio de resolución (MTTR) al eliminar el paso manual de triage.
Atención ciudadana por voz. Un agente de voz recibe reclamos, los registra automáticamente y resuelve consultas frecuentes sin derivar a un operador humano, algo especialmente valioso en municipios con volumen alto y personal limitado.
Automatización de cobranzas. El agente contacta proactivamente a deudores por WhatsApp o llamada, negocia planes de pago dentro de reglas predefinidas y escala solo los casos que requieren criterio humano, mejorando la tasa de contacto efectivo.
Ventas y calificación de leads. El agente responde consultas iniciales, califica el interés del prospecto y agenda reuniones directamente en el calendario del vendedor.

En atención ciudadana, un despliegue documentado logró resolver el 85 % de los casos de forma autónoma, sin necesidad de derivar a un operador humano, gestionando la totalidad del volumen de reclamos entrante. Esa cifra ilustra algo importante: la resolución autónoma no depende solo del modelo de lenguaje usado, depende de qué tan bien delimitado está el flujo de decisión que se le entrega al agente.

Para medir impacto real conviene fijar, desde el piloto, un panel simple con cuatro indicadores: tasa de resolución autónoma, tiempo medio de atención, volumen de casos derivados a humanos y satisfacción del usuario final. Comparar estos números antes y después de la integración es lo que convierte un proyecto de IA en una decisión de negocio justificable, no en un experimento tecnológico aislado.

Experiencia práctica: cómo lo hacemos en Anunzi

En Anunzi trabajamos integraciones de agentes de IA en sistemas de gestión pública y privada, y la lección más consistente es que la velocidad de despliegue depende casi por completo de qué tan bien definido está el flujo antes de empezar a conectar sistemas.

El caso de la Municipalidad de Villa María es representativo: implementamos un agente de voz operativo en 4 semanas que hoy gestiona el 100 % de los reclamos ciudadanos entrantes, resolviendo el 85 % de los casos sin derivar a un humano. Ese ritmo no fue excepcional por la tecnología en sí, sino porque el municipio llegó con un proceso de reclamos ya mapeado y reglas de escalamiento claras.

El patrón se repite fuera del sector público: clínicas y equipos comerciales que operan con agentes de Anunzi han reducido llamadas perdidas significativamente y acelerado sus tiempos de resolución de manera notable, dos métricas que casi siempre están correlacionadas cuando el cuello de botella es la disponibilidad del primer contacto.

Algunos elementos operativos que sostienen estos resultados:

Soporte, implementación y acompañamiento 100 % en español, con equipo propio en España y Argentina, sin depender de mesas de soporte genéricas en otro idioma.
Operación multicanal desde el inicio: WhatsApp, llamadas de voz y correo electrónico, con más del 95 % de resolución autónoma en los flujos ya desplegados.
Infraestructura de marca blanca disponible para partners y agencias que quieran ofrecer agentes de IA bajo su propia identidad comercial.

Estos datos importan menos como cifra aislada y más como evidencia de un patrón: los proyectos que avanzan rápido son los que llegan con el proceso de negocio ya claro, no los que esperan que la tecnología resuelva la ambigüedad por ellos.

Checklist técnico para el equipo de implementación

Antes de dar por cerrado un piloto, el equipo técnico debería poder marcar cada uno de estos puntos sin ambigüedad. Es la diferencia entre un agente que funciona en pruebas y uno que resiste el tráfico real de producción.

Confirmar tokens, alcances (scopes) y endpoints de cada radio configurado, documentando qué credencial usa cada conexión.
Validar los mapeos de tablas entre el sistema externo y el modelo de datos de ServiceNow, verificando que los campos críticos no queden vacíos.
Ejecutar pruebas de integración extremo a extremo, simulando fallos del sistema externo para confirmar que el agente degrada correctamente.
Realizar pruebas de seguridad sobre las credenciales y permisos de cada radio, revisando que ningún token tenga privilegios de más.
Medir el rendimiento del flujo completo bajo carga simulada, no solo la respuesta aislada del modelo de lenguaje.
Configurar dashboards de monitorización en producción antes del lanzamiento, no después.

Elemento a monitorizar	Qué revisar en producción
Tasa de resolución autónoma	Porcentaje de casos resueltos sin intervención humana, por canal y por tipo de consulta.
Tiempo medio de atención	Duración desde que el usuario inicia el contacto hasta la resolución o derivación.
Errores de conexión de radios	Frecuencia de fallos al conectar con sistemas externos y su impacto en el flujo del agente.
Casos derivados a humanos	Volumen y motivo de las derivaciones, para ajustar las reglas del agente.
Uso de credenciales	Accesos activos por radio y última fecha de rotación de tokens.

La lección que la mayoría de los proyectos aprende demasiado tarde

Lo que el mercado suele vender como «integrar IA en ServiceNow» y lo que realmente determina el éxito de un piloto son dos cosas distintas. El discurso habitual se centra en el modelo de lenguaje: cuál es más potente, cuál genera mejores respuestas. La evidencia real apunta a otro lado: el factor que más predice si un piloto escala es qué tan bien delimitado está el flujo de decisión antes de conectar cualquier sistema.

La conveniencia de la arquitectura unificada de ServiceNow, con su modelo de datos y gobernanza centralizada, hace fácil subestimar el trabajo de definición previa. Es tentador pensar que, como la plataforma ya resuelve la parte técnica, el proyecto se reduce a activar plugins y escribir un buen prompt. No es así: los proyectos que fallan casi siempre fallan por ambigüedad de negocio, no por limitaciones de Integration Hub o del motor de agentes.

Si tuviera que priorizar un solo consejo para un responsable técnico que arranca este proceso, sería este: invierte más tiempo mapeando el proceso actual con quienes lo ejecutan hoy que evaluando qué modelo de lenguaje usar. La tecnología ya está madura. La ambigüedad organizacional es lo que sigue retrasando los pilotos.

— Matias

Cómo Anunzi acelera la integración de agentes de IA con ServiceNow

Si ya evaluaste el camino de construir la integración con tu propio equipo técnico, sabes que el reto no es la plataforma, es el tiempo que toma diseñar, probar y ajustar el flujo del agente antes de confiar en él. Anunzi resuelve exactamente ese tramo: diseñamos e implementamos agentes de IA a medida, integrados a tus sistemas existentes, con despliegues que en casos documentados tomaron cuatro semanas de principio a fin.

Si tu organización necesita revender esta capacidad bajo su propia marca, también ofrecemos infraestructura de marca blanca para partners y agencias. Y si tu prioridad inmediata es reducir tiempos de atención antes de escalar a un proyecto completo, puedes revisar cómo otros equipos lo lograron con IA conversacional.

El siguiente paso es simple: prueba un agente de Anunzi en tiempo real y evalúa con tu propio equipo técnico si el flujo se ajusta al caso de uso que tienes en mente antes de comprometer presupuesto en un desarrollo interno.

Puntos clave

Integrar IA en ServiceNow funciona cuando se combina AI Platform, Integration Hub y agentes bien delimitados, y falla cuando el proceso de negocio no está claro antes de empezar.

Punto	Detalles
Usa el patrón estándar	Despliega agentes sobre AI Platform y conecta sistemas con Integration Hub antes de considerar desarrollos a medida.
Resuelve prerrequisitos primero	Confirma licencias, calidad de datos y métricas de éxito acordadas con negocio antes del piloto.
Sigue el orden de conectividad	Prioriza radios predefinidos, luego el generador de radios con OpenAPI y por último tablas remotas.
Gobierna con la Torre de control de IA	Audita credenciales, decisiones del agente y trazabilidad desde el primer despliegue.
Anunzi como vía de implementación	Anunzi despliega agentes multicanal en semanas, con soporte en español y casos documentados como el de Villa María.

Fuentes

Para profundizar en la arquitectura y en los patrones de conectividad mencionados en esta guía:

Preguntas frecuentes

¿Qué se necesita antes de integrar IA en ServiceNow?

Licencias vigentes de AI Platform, plugins de Integration Hub habilitados, acceso limpio a los datos que usará el agente y un acuerdo claro con negocio sobre las métricas de éxito del piloto.

¿Integration Hub sirve para conectar sistemas legacy?

Sí, mediante tablas remotas o radios personalizados generados con especificaciones OpenAPI cuando el sistema legacy no tiene un conector certificado disponible.

¿Cuánto tarda un piloto típico de integración?

Un despliegue bien planificado, con el proceso de negocio ya mapeado, puede completarse en pocas semanas: Anunzi documentó un caso municipal operativo en cuatro semanas.

¿Qué modelo de lenguaje conviene usar, Now LLM o uno externo?

Un modelo externo como Azure OpenAI suele ser más rápido de validar en un piloto, mientras que Now LLM aporta más control cuando la organización tiene requisitos estrictos sobre dónde residen los datos.

¿Cómo se garantiza la gobernanza de los agentes de IA?

Mediante la Torre de control de IA, que centraliza la supervisión de modelos, credenciales y decisiones de los agentes en toda la organización, evitando despliegues descontrolados por área.