En este artículo
Un radicado que queda sin clasificar, una solicitud ciudadana que se responde tarde o un proceso académico detenido por una validación manual no suelen ser problemas de inteligencia artificial. Son problemas operativos. Un agente de inteligencia artificial puede intervenirlos cuando se diseña para trabajar sobre reglas, datos, permisos y sistemas reales de la organización, no solo para conversar.
La diferencia es relevante para entidades públicas, universidades y empresas con plataformas críticas. Un asistente que redacta textos puede aportar productividad individual. Un agente, en cambio, puede interpretar una solicitud, consultar fuentes autorizadas, decidir el siguiente paso dentro de límites definidos, ejecutar una acción en un sistema y dejar evidencia de lo ocurrido. Para que eso sea útil en producción, la arquitectura importa tanto como el modelo de lenguaje.
Qué hace un agente de inteligencia artificial
Un agente de inteligencia artificial es un componente de software capaz de percibir información de su entorno, razonar sobre un objetivo y ejecutar acciones mediante herramientas conectadas. Su valor no está en producir una respuesta aparentemente inteligente, sino en completar una parte acotada de un proceso con resultados verificables.
Por ejemplo, un agente para atención institucional puede recibir una consulta desde el portal web, identificar su intención, recuperar información de una base documental vigente, consultar el estado de un trámite mediante una API y preparar una respuesta ajustada al caso. Si la solicitud exige una decisión administrativa o incluye información sensible, el agente debe escalarla a una persona, no improvisar una respuesta ni alterar un registro.
Esta capacidad combina varios elementos. El modelo de inteligencia artificial interpreta lenguaje y contexto. Un mecanismo de recuperación de información, como RAG, aporta documentos y datos pertinentes. Las integraciones permiten consultar o actualizar plataformas existentes. Finalmente, una capa de orquestación define qué herramientas puede usar el agente, en qué orden, con qué credenciales y bajo qué condiciones.
No todos los casos requieren el mismo nivel de autonomía. En procesos de bajo riesgo, el agente puede ejecutar acciones repetitivas, como clasificar solicitudes o actualizar campos previamente validados. En procesos regulados o de alto impacto, conviene que recomiende una acción y que un responsable la apruebe. La autonomía no es un objetivo por sí mismo: debe corresponder al riesgo, la calidad de los datos y la capacidad de supervisión disponible.
Del chatbot aislado al flujo operativo controlado
Un chatbot generalista responde desde una ventana de conversación. Puede ser útil como punto de acceso, pero no constituye por sí solo una solución institucional. Si no conoce las fuentes oficiales, no diferencia versiones documentales, no respeta perfiles de acceso y no registra sus decisiones, su incorporación a un proceso crítico crea más incertidumbre de la que resuelve.
Un agente bien implementado opera dentro de un flujo definido. Primero recibe una entrada: una petición de servicio, un formulario, un correo o un evento generado por otro sistema. Después verifica datos mínimos, consulta fuentes autorizadas y determina si cuenta con evidencia suficiente para continuar. Luego ejecuta una acción permitida o envía el caso a revisión humana. Cada paso debe quedar asociado a registros de auditoría.
Pensemos en una universidad que recibe solicitudes de homologación. El agente puede leer los documentos aportados, extraer datos relevantes, contrastarlos con reglas académicas vigentes y preparar un expediente para el analista. No debería aprobar una homologación de forma autónoma si la norma exige evaluación humana. Sin embargo, puede reducir tiempos de preparación, detectar documentación faltante y priorizar casos según criterios explícitos.
En una entidad pública, el mismo principio aplica a los flujos editoriales y de atención. Un agente puede sugerir etiquetas para contenidos, revisar que una publicación incluya metadatos obligatorios, identificar enlaces rotos o responder preguntas frecuentes con base en información institucional aprobada. Para publicar, modificar contenidos oficiales o acceder a datos personales, necesita controles adicionales y permisos diferenciados.
RAG: conocimiento institucional antes que respuestas plausibles
La recuperación aumentada por generación, conocida como RAG, permite que el agente consulte una base de conocimiento antes de formular una respuesta. No se trata simplemente de cargar archivos a un modelo. Requiere seleccionar fuentes confiables, estructurar documentos, conservar su vigencia, definir metadatos y establecer qué repositorios son accesibles para cada perfil.
Una respuesta basada en un documento desactualizado puede ser más perjudicial que una respuesta que admita no tener información suficiente. Por eso, la calidad de un sistema RAG depende de la gobernanza documental: responsables editoriales, fechas de actualización, control de versiones, criterios de publicación y mecanismos para retirar información obsoleta.
También debe existir trazabilidad. Cuando un agente ofrece una recomendación o responde una consulta institucional, la organización necesita saber qué fuentes consultó, qué versión estaba vigente y por qué ejecutó una acción. Esta evidencia facilita auditorías, mejora continua y corrección de errores.
Arquitectura para agentes que puedan operar y evolucionar
La implementación de agentes no empieza con la elección de un modelo. Empieza con una pregunta operativa: ¿qué proceso específico tiene suficiente volumen, reglas claras y datos disponibles para justificar la automatización? Un caso bien delimitado permite medir resultados, contener riesgos y aprender antes de ampliar el alcance.
Una arquitectura empresarial para agentes suele separar claramente las responsabilidades. La interfaz puede estar integrada a un portal Drupal, una intranet, una aplicación de atención o un canal interno. La capa de orquestación administra instrucciones, herramientas, estados y rutas de aprobación. Las integraciones conectan sistemas de gestión documental, CRM, ERP, mesas de servicio o bases de datos. Los servicios de identidad y seguridad controlan quién puede solicitar, aprobar o ejecutar cada acción.
Esta separación evita que la lógica de negocio quede escondida en una instrucción extensa y difícil de mantener. Las reglas determinísticas, como validar un formato, aplicar una política de permisos o calcular un indicador, deben seguir siendo software verificable. El modelo puede ayudar a interpretar texto no estructurado, resumir información o elegir entre rutas previamente autorizadas, pero no debería sustituir controles que necesitan comportamiento predecible.
Cuando intervienen varios agentes, la orquestación adquiere mayor relevancia. Un agente puede especializarse en consultar normativas, otro en revisar datos de una solicitud y otro en preparar una respuesta. Sin una coordinación explícita, esa distribución genera duplicación, respuestas contradictorias y costos difíciles de prever. El flujo debe definir qué agente tiene autoridad sobre cada tarea, cuándo comparte contexto y en qué momento se detiene.
Seguridad, permisos y acciones acotadas
Conectar un agente a sistemas existentes cambia el tipo de riesgo. Ya no basta con revisar si una respuesta es correcta: hay que proteger credenciales, limitar accesos y prevenir acciones indebidas. Un agente que puede consultar un sistema de información no necesariamente debe poder modificarlo. Uno que puede preparar un oficio no debe enviarlo sin aprobación si el proceso lo exige.
Las acciones deben ser acotadas, auditables y medibles. Esto implica usar permisos de mínimo privilegio, separar ambientes de pruebas y producción, validar parámetros antes de llamar una API y registrar cada herramienta utilizada. También exige prevenir instrucciones maliciosas incluidas en documentos, correos o sitios externos que el agente pueda consultar.
La protección de datos personales requiere un tratamiento particular. Antes de enviar información a un modelo o proveedor externo, la organización debe definir qué datos son necesarios, cuáles deben anonimizarse y dónde se procesarán. En algunos escenarios, por requisitos normativos, contractuales o de sensibilidad, será preferible utilizar modelos desplegados en entornos controlados o limitar el agente a datos no sensibles.
Cómo medir si el agente aporta valor
Una demostración puede impresionar por la fluidez de una conversación. Un proyecto serio se evalúa por indicadores operativos. Según el caso, pueden medirse el tiempo promedio de atención, el porcentaje de solicitudes correctamente clasificadas, la reducción de reprocesos, la tasa de escalamiento humano, el cumplimiento de acuerdos de nivel de servicio y la satisfacción de usuarios y equipos internos.
También conviene medir la calidad de las decisiones. Si el agente recomienda documentos equivocados, consulta fuentes sin vigencia o aumenta las excepciones manuales, una reducción superficial de tiempos no representa una mejora. La evaluación debe realizarse con casos reales, incluyendo solicitudes ambiguas, incompletas y poco frecuentes. Los casos límite revelan mejor que una demostración dónde deben estar los controles.
El costo es otro criterio práctico. Cada consulta a un modelo, cada búsqueda documental y cada integración tiene impacto técnico y financiero. Un diseño eficiente no usa inteligencia artificial para tareas que una regla simple puede resolver. Combinar automatización determinística, workflows convencionales y agentes permite reservar el razonamiento probabilístico para los puntos donde aporta una ventaja clara.
Una implementación que empieza por el proceso
La adopción responsable suele avanzar por etapas. Primero se identifica un proceso con dolor operativo comprobable y responsables definidos. Luego se revisan sus datos, reglas, sistemas involucrados y riesgos. Con esa base se construye un piloto con alcance limitado, supervisión humana y métricas acordadas. Solo después de validar resultados tiene sentido ampliar integraciones, autonomía o cobertura.
Este enfoque evita dos extremos habituales: proyectos que se quedan en una demostración sin conexión con la operación, y automatizaciones demasiado ambiciosas que intentan intervenir procesos críticos sin datos ni controles suficientes. La tecnología aplicada con criterio de arquitectura y continuidad permite evolucionar a partir de evidencia, sin comprometer la estabilidad de las plataformas existentes.
Para organizaciones que deben sostener servicios digitales de alta responsabilidad, el agente no debería ser una capa llamativa sobre sistemas fragmentados. Debe convertirse en una capacidad gobernada, conectada con el proceso correcto y preparada para rendir cuentas sobre cada acción que realiza.