En este artículo
Un agente que consulta contratos, responde a ciudadanos o propone decisiones de crédito puede ahorrar horas de operación. También puede revelar información reservada, inventar una respuesta con apariencia convincente o ejecutar una acción indebida si se conecta sin controles a los sistemas institucionales. Los riesgos de la inteligencia artificial no aparecen solo cuando el modelo falla: surgen cuando una capacidad probabilística se incorpora a un proceso que exige seguridad, contexto, responsabilidad y continuidad.
Para una entidad pública, una universidad o una empresa con plataformas críticas, la discusión no debería limitarse a elegir un modelo o comparar licencias. La pregunta relevante es qué decisiones podrá apoyar la inteligencia artificial, qué información procesará, quién responderá por sus resultados y cómo se mantendrá el servicio cuando cambien los datos, las reglas del negocio o el proveedor tecnológico.
Riesgos de la inteligencia artificial que deben gestionarse
La IA generativa puede producir texto, clasificar documentos, extraer información y coordinar tareas con una velocidad útil para áreas de atención, comunicaciones, conocimiento, operaciones y tecnología. Sin embargo, su resultado no equivale automáticamente a una fuente verificada. Un modelo puede generar una afirmación incorrecta, omitir una excepción normativa o citar una referencia inexistente. En un entorno institucional, una respuesta plausible pero falsa puede afectar la confianza de los usuarios, inducir decisiones erradas o comprometer el cumplimiento regulatorio.
Este riesgo se conoce con frecuencia como alucinación, pero el nombre no debe simplificar el problema. La causa puede estar en una consulta ambigua, documentos desactualizados, una recuperación deficiente de información, instrucciones contradictorias o un modelo que no tiene conocimiento suficiente del dominio. Reducirlo exige diseñar el sistema completo, no solo redactar mejores instrucciones.
Un enfoque RAG, que recupera contenido desde fuentes controladas antes de generar una respuesta, ayuda a limitar el alcance de la información. Aun así, no reemplaza la curaduría documental, los permisos de acceso ni la validación de las fuentes. Si el repositorio contiene resoluciones vencidas o versiones contradictorias de un procedimiento, el sistema puede responder con confianza a partir de contenido igualmente problemático.
La privacidad y la confidencialidad constituyen otro frente decisivo. Cargar bases de datos, expedientes, conversaciones internas o información personal en una herramienta externa sin una evaluación previa puede exponer datos sujetos a reserva, protección legal o secreto empresarial. El riesgo no se resuelve con una prohibición general de uso. Requiere clasificar la información, definir qué datos pueden procesarse, aplicar minimización y anonimización cuando corresponda, y establecer acuerdos claros sobre almacenamiento, retención y uso por parte de terceros.
También existe un riesgo de seguridad operacional. Cuando un agente de IA puede consultar un CRM, crear tickets, modificar registros, enviar correos o activar flujos de trabajo, deja de ser únicamente una interfaz conversacional. Se convierte en un componente con capacidad de actuar. Una instrucción maliciosa incluida en un documento, un correo o una página web puede intentar alterar su comportamiento y llevarlo a revelar datos o ejecutar acciones fuera de su propósito.
Por eso, los agentes conectados a sistemas existentes deben operar con privilegios mínimos. No es razonable otorgarles acceso general a una plataforma solo porque necesitan completar una tarea específica. Las acciones deben estar acotadas, auditables y medibles: consultar un estado, proponer una respuesta, crear un borrador o escalar un caso. Las acciones irreversibles, financieras, regulatorias o que afectan derechos de personas requieren reglas adicionales y, en muchos casos, aprobación humana.
El problema no es solo técnico: sesgo, contexto y responsabilidad
Los modelos aprenden patrones de datos y lenguaje que pueden contener sesgos históricos, simplificaciones culturales o representaciones insuficientes de ciertos grupos. Si se usan para priorizar solicitudes, apoyar selección de personal, clasificar beneficiarios o recomendar intervenciones, esos sesgos pueden traducirse en resultados discriminatorios o difíciles de justificar.
No todos los usos tienen el mismo nivel de exposición. Un asistente que resume actas internas presenta un riesgo distinto al de un sistema que influye en el acceso a un servicio público o una oportunidad laboral. La evaluación debe considerar el impacto de una decisión errada, la posibilidad de revisión, la población afectada y la disponibilidad de mecanismos de reclamación.
La explicabilidad también depende del caso de uso. No siempre será posible describir cada cálculo interno de un modelo complejo, pero sí se debe poder explicar el propósito del sistema, los datos que consulta, sus límites, las reglas que restringen su actuación y el responsable del proceso. Esta trazabilidad es indispensable para auditorías, incidentes y mejora continua.
Un error habitual es asignar la responsabilidad al proveedor del modelo o al equipo que construyó la integración. La responsabilidad institucional no desaparece por tercerizar infraestructura. Las áreas dueñas del proceso deben definir criterios de calidad, validar casos críticos y participar en la gestión de cambios. Tecnología aporta arquitectura, seguridad, integración y monitoreo; negocio aporta el contexto que permite determinar si una respuesta es útil, adecuada y permitida.
Gobernar antes de escalar
Una adopción segura comienza por seleccionar procesos donde el beneficio sea verificable y el impacto de un error pueda controlarse. La automatización de consultas repetitivas sobre documentación aprobada, la clasificación inicial de solicitudes o la generación de borradores revisables suelen ser mejores puntos de partida que delegar decisiones sensibles de extremo a extremo.
Antes de poner una solución en producción, conviene documentar el objetivo, los usuarios, las fuentes de datos, los permisos, las integraciones, los criterios de aceptación y los escenarios de falla. Esa definición permite distinguir entre un prototipo atractivo y una capacidad operativa que puede sostenerse.
La arquitectura debe incorporar controles desde el diseño. Esto incluye autenticación, autorización por roles, segmentación de entornos, cifrado, registro de eventos y límites de consumo. En soluciones con RAG, debe existir una estrategia para versionar fuentes, retirar documentos obsoletos y respetar los permisos de cada usuario al momento de recuperar información. Un colaborador no debería obtener mediante una conversación con IA un documento al que no podría acceder desde el repositorio original.
La evaluación tampoco puede quedarse en una demostración con preguntas favorables. Es necesario probar consultas ambiguas, solicitudes fuera de alcance, datos incompletos, instrucciones maliciosas, documentos contradictorios y casos propios del dominio. Las métricas deben medir precisión y utilidad, pero también tasa de escalamiento a una persona, respuestas sin sustento, intentos bloqueados y tiempos de corrección.
El monitoreo posterior es igual de relevante. Los modelos, las fuentes de conocimiento y los procesos cambian. Una respuesta que era correcta hace tres meses puede dejar de serlo tras una actualización normativa o una modificación del catálogo de servicios. La operación debe contemplar revisión periódica, gestión de incidentes, canales de retroalimentación y una ruta para desactivar funciones si se detecta un comportamiento no aceptable.
Integrar IA sin fragmentar la operación
Muchas organizaciones adquieren herramientas aisladas para resolver necesidades puntuales. El resultado puede ser una colección de asistentes sin gobierno común, duplicación de datos, costos difíciles de prever y experiencias inconsistentes para usuarios y equipos internos. El riesgo crece cuando cada área conecta su propia solución a sistemas críticos sin estándares compartidos.
La alternativa no es centralizar toda innovación en un único proyecto lento. Es definir una arquitectura de referencia que permita experimentar con control: componentes reutilizables de identidad, gestión de secretos, conectores, observabilidad, repositorios documentales y reglas para el uso de modelos. Así, cada iniciativa puede avanzar sin comprometer la seguridad ni crear nuevas dependencias opacas.
Para plataformas institucionales, esta mirada debe incluir la experiencia digital. Un asistente integrado a un portal debe respetar accesibilidad, lenguaje claro, flujos editoriales y mecanismos visibles para que el usuario comprenda cuándo interactúa con una IA y cuándo puede solicitar atención humana. La tecnología aplicada con criterio de arquitectura y continuidad protege tanto la operación como la confianza pública.
La adopción responsable es una capacidad permanente
Gestionar los riesgos de la inteligencia artificial no significa frenar su uso ni esperar a que exista certeza absoluta. Significa reconocer que el valor de la IA depende de decisiones de diseño, gobierno y operación que deben mantenerse en el tiempo. El modelo es solo una parte de la solución; los datos, las integraciones, las personas y los controles determinan si esa solución será confiable.
Las organizaciones que obtendrán mejores resultados no serán necesariamente las que implementen más asistentes en menos tiempo. Serán las que conviertan cada implementación en una capacidad administrable: con propósito definido, evidencia de desempeño, límites claros y responsables identificables. Allí la IA deja de ser una demostración puntual y empieza a aportar valor sin poner en riesgo la continuidad que la organización necesita proteger.