El cambio más importante de la inteligencia artificial ya no está sólo en la calidad de sus respuestas. Está en su capacidad para actuar. En 2026, la conversación dejó de centrarse exclusivamente en los chatbots que generan texto y comenzó a girar alrededor de agentes capaces de navegar, escribir código, utilizar herramientas y perseguir objetivos durante varios pasos. Este desplazamiento plantea una pregunta decisiva para empresas, gobiernos y usuarios: ¿cuánta autonomía puede concederse antes de que el sistema se vuelva difícil de supervisar?
La respuesta no puede encontrarse en una sola puntuación de referencia. Un agente puede comportarse muy bien en una prueba controlada y, sin embargo, actuar de manera imprevisible cuando enfrenta permisos ambiguos, datos incompletos, instrucciones contradictorias o un sistema externo que nunca formó parte de su evaluación. El desafío central, por tanto, no es la autonomía por sí misma. Es la autonomía sin suficiente visibilidad, límites ni responsabilidad.
La nueva unidad de riesgo es una acción
Un asistente convencional suele producir un resultado que una persona revisa antes de que ocurra algo. Un agente es diferente: puede abrir un navegador, enviar una solicitud, modificar un archivo, ejecutar código, consultar una base de datos o activar un flujo de trabajo. Cada paso puede ser útil, pero también abre una nueva superficie de error. Una frase equivocada suele poder corregirse. Una transferencia, eliminación o modificación de permisos equivocada puede convertirse en un incidente.
Esto transforma la manera en que deben diseñarse los sistemas de IA. La pregunta relevante ya no es únicamente si un modelo es preciso. También debemos saber si el sistema que lo rodea puede explicar qué intentó hacer el agente, qué herramienta utilizó, en qué información se apoyó, qué autoridad tenía y cómo puede una persona detener o revertir el proceso. El producto ya no es sólo el modelo: es el modelo junto con sus permisos, memoria, herramientas, registros y procedimientos de recuperación.
La capacidad avanza más rápido que la divulgación
El primer informe preliminar del Independent International Scientific Panel on AI de las Naciones Unidas, presentado en 2026, plantea el debate como un problema científico y de gobernanza, no como una competencia de mercadotecnia. Su importancia está en exigir que las decisiones públicas se apoyen en evidencia sobre capacidades, oportunidades, riesgos e impactos. Esto importa porque los sistemas más relevantes no permanecerán dentro de un laboratorio: se integrarán en centros de trabajo, servicios públicos, operaciones financieras e infraestructura digital.
El seguimiento independiente apunta a un segundo problema: el registro público sobre seguridad es mucho menor que el registro público sobre capacidades. El AI Agent Index 2025 documenta 30 agentes destacados y señala que sólo cuatro de los 13 sistemas identificados con niveles de autonomía de frontera divulgan evaluaciones de seguridad agéntica. También encuentra que 25 de los 30 agentes no publican resultados internos de seguridad y que 23 no informan pruebas de terceros. Estas cifras no demuestran que los sistemas sean inseguros. Sí muestran que usuarios y compradores suelen disponer de menos evidencia sobre seguridad que sobre funcionalidades.
Qué exige una agencia confiable
Un agente creíble debe construirse alrededor de una cadena de controles comprensible para alguien que no pertenezca al equipo de ingeniería.
Privilegios mínimos: el agente debe recibir sólo los permisos necesarios para la tarea y únicamente durante el tiempo indispensable.
Aprobación humana en los límites relevantes: transferencias, publicaciones, eliminaciones, cambios de acceso y mensajes externos deben requerir un punto de revisión deliberado.
Ejecución trazable: el sistema debe conservar un registro legible de instrucciones, llamadas a herramientas, materiales consultados, decisiones y fallos.
Evaluación adversarial: las pruebas deben incluir instrucciones ambiguas, inyección de instrucciones, extracción de datos, objetivos en conflicto e intentos de eludir la supervisión.
Recuperación desde el diseño: el usuario debe poder revocar accesos, detener un proceso activo y restaurar un estado anterior sin tener que negociar con el agente.
No se trata de ideales abstractos. Son requisitos de producto. Una empresa que no puede responder quién autorizó una acción, qué información fue expuesta o cómo se interrumpió un proceso no está operando un flujo inteligente: está trasladando la responsabilidad a una dependencia opaca.
La pregunta institucional
La regulación será importante, pero por sí sola no creará sistemas confiables. Los equipos de compras, consejos directivos, universidades y organismos públicos también necesitan preguntas prácticas: ¿qué puede hacer este agente sin aprobación? ¿Qué evidencia respalda sus afirmaciones de seguridad? ¿Cada cuánto se repiten las evaluaciones después de cambiar el modelo o una herramienta? ¿Quién recibe los reportes de incidentes? ¿Qué registros se conservan y quién puede inspeccionarlos?
Para las organizaciones de México y América Latina, la transparencia es especialmente importante. La adopción tecnológica suele producirse mediante una combinación de servicios en la nube, proveedores y flujos configurados localmente. Si un agente toma una decisión dentro de esa cadena, la responsabilidad no puede desaparecer porque el modelo subyacente fue construido en otro país. Los contratos, los derechos de auditoría, la gobernanza de datos, la cobertura lingüística y las rutas de escalamiento deben formar parte del despliegue, no ser un trámite posterior.
De las demostraciones impresionantes a los sistemas confiables
La siguiente etapa de la IA no se decidirá únicamente por el laboratorio que produzca el modelo más capaz. También dependerá de qué empresas puedan convertir esa capacidad en agencia confiable. Los sistemas más sólidos harán visibles sus límites: mostrarán qué sabe el agente, qué puede hacer, qué no puede hacer y cuándo debe intervenir una persona.
La autonomía es valiosa cuando reduce fricción sin trasladar un riesgo invisible al usuario. El objetivo no debería ser crear sistemas que actúen como si fueran humanos, sino sistemas cuyas acciones permanezcan comprensibles, acotadas y sujetas a responsabilidad. En una época de agentes cada vez más capaces, la confianza se medirá menos por la seguridad con que habla un sistema y más por la claridad con que puede supervisarse.
La confianza en los agentes depende de la trazabilidad, los permisos y la supervisión humana.
El giro hacia los agentes cambia el diseño del sistema
El paso de los chatbots a los agentes suele describirse como si fuera una simple mejora en la capacidad del modelo. La descripción es incompleta. Un chatbot normalmente espera una instrucción, predice una respuesta y devuelve el control a la persona. Un agente se coloca dentro de un ciclo: recibe un objetivo, interpreta una situación, elige una herramienta, observa el resultado, revisa su plan y continúa hasta considerar que alcanzó la meta. El ciclo puede ser muy útil, pero cambia el objeto que debe gobernarse. La unidad relevante ya no es la frase producida por un modelo, sino la secuencia de acciones que ejecuta un sistema habilitado por un modelo.
Esa secuencia está formada por varias capas. Existe un modelo fundacional que genera predicciones; una instrucción o política que define su función; una capa de memoria que almacena información; una capa de recuperación que selecciona documentos; una capa de herramientas que conecta navegadores, bases de datos o programas; una capa de ejecución que aplica cambios; y una interfaz mediante la cual una persona concede o revoca autoridad. Una falla en cualquiera de estas capas puede cambiar el resultado. Un modelo puede ser preciso mientras la recuperación entrega el documento equivocado. Una herramienta puede funcionar de acuerdo con su diseño mientras el agente elige la cuenta incorrecta. Un permiso puede ser legítimo en términos generales y, sin embargo, resultar excesivo para una tarea concreta.
Por eso las demostraciones de capacidad pueden ser engañosas. Un sistema puede escribir código competente en una prueba limpia y fallar cuando un repositorio contiene una instrucción ambigua. Puede resumir correctamente una política y aplicarla mal cuando un caso tiene información incompleta. Puede navegar un sitio durante una demostración y realizar una compra inaceptable cuando no existe un umbral de aprobación explícito. La diferencia entre una demostración y un sistema confiable no es cosmética: es la diferencia entre mostrar que una acción es posible y demostrar que la acción está delimitada.
Para los equipos de producto, la consecuencia es directa: la autonomía debe acotarse antes de optimizarse. Antes de decidir cuántos pasos puede ejecutar un agente, el equipo debe definir el objetivo, los recursos, las herramientas, el periodo de vigencia, los dominios de datos y las fronteras de decisión. También debe establecer cuándo el sistema debe detenerse, pedir una aclaración o devolver el control. Un sistema que no puede expresar esos límites no tiene solamente documentación incompleta; carece de una parte de su arquitectura.
Por qué una acción no es lo mismo que una respuesta
Las respuestas y las acciones tienen perfiles de riesgo distintos. Una explicación defectuosa puede corregirse en el siguiente mensaje. Una acción defectuosa puede crear un compromiso fuera de la conversación: enviar un mensaje, borrar un archivo, iniciar un pago, modificar un permiso o publicar un texto. La posibilidad de revertirla también cambia. Algunas acciones se deshacen con un clic; otras producen consecuencias jurídicas, financieras o reputacionales que no pueden recuperarse por completo.
Un modelo útil de riesgo comienza, por tanto, con la superficie de acción. Esta superficie incluye todos los efectos externos que un agente puede provocar, de forma directa o indirecta. Leer una página pública tiene un perfil. Consultar una base de datos privada tiene otro. Preparar un correo no es lo mismo que enviarlo. Elaborar una orden de compra no equivale a aprobarla. Ejecutar una prueba en un entorno aislado es diferente de correr una migración en producción. El mismo modelo puede ser aceptable en el primer contexto e inaceptable en el segundo porque cambió la autoridad que lo rodea.
Los equipos deben inventariar esa superficie con lenguaje claro. ¿Qué sistemas puede consultar el agente? ¿Qué registros puede leer? ¿Cuáles puede modificar? ¿Puede comunicarse con terceros? ¿Puede crear obligaciones financieras? ¿Puede exponer información personal? ¿Puede ejecutar código? ¿Puede delegar tareas en otro agente? El inventario debe considerar capacidades intencionales y accidentales, porque las integraciones amplían la autoridad con el tiempo. Un conector agregado por comodidad puede convertirse en una vía de filtración si el modelo de permisos no se actualiza.
El inventario debe acompañarse de una taxonomía de acciones. Las acciones de bajo impacto pueden ejecutarse automáticamente si son reversibles y fáciles de inspeccionar. Las de impacto medio pueden requerir una cola de revisión, una segunda señal o un límite de transacción. Las de alto impacto deben requerir, por regla general, una aprobación humana explícita en el momento de ejecutarse. La taxonomía no debe depender únicamente del nivel de confianza del modelo. La confianza describe una predicción; no demuestra que la decisión sea adecuada, autorizada o justa.
La importancia oculta del contexto
A los agentes se les reconoce la capacidad de conservar contexto entre pasos, pero el contexto no es automáticamente una virtud. Más información puede mejorar una respuesta cuando es pertinente, actual y está autorizada. También puede generar confusión cuando una instrucción antigua se trata como vigente, cuando información sensible se arrastra a una tarea ajena o cuando un documento recuperado contiene una instrucción diseñada para manipular al sistema. Un agente confiable necesita límites de contexto, no únicamente una memoria más grande.
Un principio práctico es separar el contexto de la tarea del contexto de identidad. El primero contiene el material necesario para cumplir el objetivo actual. El segundo contiene información sobre la persona, la organización o la cuenta que interactúa con el sistema. Mezclarlos indiscriminadamente dificulta determinar qué podía utilizar el agente. Otro principio es identificar el origen y la vigencia del material recuperado. Una política vigente, un documento histórico, una nota aportada por el usuario y una página web no verificada no deberían parecer idénticos dentro del flujo interno.
El contexto también debe minimizarse en el punto de uso. Si un agente agenda una reunión, quizá necesita la disponibilidad y los participantes, pero no una base completa de clientes. Si prepara una investigación jurídica, necesita las autoridades relevantes, pero no historiales personales ajenos. Minimizar reduce las consecuencias de un error y vuelve más comprensible la auditoría. También mejora el rendimiento porque reduce el número de instrucciones y datos que compiten por la atención del modelo.
La pregunta no es si un sistema puede recordarlo todo. Es si puede explicar por qué utilizó un dato específico para ejecutar una acción concreta. Esa explicación debe estar disponible para la persona responsable del flujo de trabajo, no únicamente para el equipo que construyó el modelo. Sin esa visibilidad, la memoria se convierte en una forma invisible de autoridad.
Planear no equivale a autorizar
Hay otra distinción fundamental: un plan no es una autorización. Un agente puede construir una secuencia excelente de pasos y, aun así, no tener derecho a ejecutar ninguno. La capa de planificación debe tratarse como una propuesta hasta que la política correspondiente confirme que los pasos están permitidos. Esto es especialmente importante cuando el agente puede modificar su propio plan después de recibir información nueva.
Un flujo seguro puede mostrar el plan antes de ejecutarlo, identificar las herramientas que pretende utilizar y marcar las etapas que requieren aprobación. También puede ofrecer un modo de simulación en el que el agente reúne información y calcula consecuencias sin modificar el estado externo. Después, solamente los pasos aprobados se convierten en llamadas ejecutables. Este enfoque no elimina todo el riesgo, pero hace visible la transición entre razonar y actuar.
La distinción también ayuda a asignar responsabilidad. Una persona puede aprobar una meta sin aprobar todos los métodos para alcanzarla. Una responsable de compras puede autorizar la búsqueda de proveedores sin aprobar una orden. Una funcionaria puede pedir un análisis sin autorizar la publicación de una conclusión. Una jefatura puede solicitar un borrador sin permitir que el sistema contacte a un cliente. Los agentes deben conservar esas diferencias en lugar de interpretar una solicitud amplia como una delegación ilimitada.
Los sistemas más maduros convertirán la autorización en un objeto de primera clase. Registrarán quién la concedió, qué cubre, cuándo expira, a qué herramientas aplica y qué acciones siguen excluidas. Puede parecer burocrático, pero la alternativa es dejar que una instrucción vaga se convierta en un permiso permanente. Esa es precisamente la autonomía invisible que suele producir incidentes.
Controles que deben formar parte del producto
La confianza no se crea con un filtro de seguridad colocado en el borde del sistema. Se crea mediante una cadena de controles que funcionan en conjunto. El primero es el privilegio mínimo. Un agente debe recibir el conjunto más pequeño de permisos capaz de completar la tarea, y esos permisos deben expirar cuando termina. Un agente de investigación puede leer una colección definida sin editarla. Uno de atención al cliente puede proponer un reembolso dentro de un límite, pero no modificar el límite. Uno de programación puede ejecutar pruebas en un entorno aislado, pero no desplegar a producción sin una compuerta de liberación.
El segundo es la separación de funciones. La persona o servicio que solicita una acción no siempre debe ser la misma autoridad que la aprueba. En una organización pequeña puede implementarse mediante una revisión de dos personas para las transacciones de alto impacto. En una organización grande puede codificarse en un flujo con controles por rol. El principio es conocido, pero los agentes lo vuelven más urgente porque una sola instrucción en lenguaje natural puede combinar análisis, decisión y ejecución en una cadena opaca.
El tercero es un punto de control claro. La revisión humana sólo es útil cuando ocurre en el momento adecuado y presenta la información adecuada. Una casilla que dice “continuar” no representa supervisión significativa si la persona no puede ver los cambios propuestos, las fuentes, las cuentas afectadas o las consecuencias de un error. Un buen punto de control resume la acción en lenguaje ordinario, muestra la incertidumbre, destaca condiciones inusuales y hace que rechazar sea tan sencillo como aprobar.
El cuarto es la trazabilidad. Los registros deben mostrar el objetivo recibido, los permisos disponibles, las herramientas utilizadas, la información recuperada, las decisiones propuestas, las aprobaciones concedidas y el estado final. Deben distinguir lo que generó el modelo de lo que efectivamente ejecutó el sistema. Es necesario conservar contexto suficiente para reconstruir un incidente sin almacenar más información sensible de la necesaria. La retención debe definirse por anticipado y el acceso limitarse a quienes lo requieren para supervisión, seguridad u obligaciones legales.
El quinto es la recuperación. El usuario debe poder detener un agente mientras corre, revocar un token, aislar una tarea y restaurar un estado anterior. La recuperación no puede depender de convencer al agente para que coopere. Debe ofrecerla el sistema que lo rodea y debe probarse como cualquier otra capacidad operativa. Un flujo con buena prevención pero sin recuperación confiable sigue siendo frágil, porque ninguna evaluación anticipa todas las interacciones con el mundo real.
Evaluar después de la demostración
La evaluación suele tratarse como una actividad de lanzamiento, pero los agentes cambian después de llegar al mercado. Se actualizan los modelos, las herramientas incorporan funciones, los índices de recuperación se renuevan, las políticas se editan y los usuarios descubren nuevas formas de formular solicitudes. Un resultado de seguridad de una versión no puede asumirse para la siguiente. Por eso las evaluaciones deben ser continuas y registrar qué cambió entre una prueba y otra.
La primera capa debe probar el desempeño ordinario. ¿Puede el agente seguir el flujo previsto, reconocer información faltante y detenerse cuando el objetivo es ambiguo? La segunda debe probar los límites. ¿Qué ocurre cuando dos instrucciones se contradicen? ¿Qué ocurre cuando una herramienta devuelve un resultado parcial? ¿Qué ocurre cuando una página externa contiene una instrucción oculta? ¿Qué ocurre cuando una cuenta no está disponible o una transacción rebasa el límite?
La tercera debe examinar comportamientos adversariales. La inyección de instrucciones es sólo un ejemplo. También deben probarse la extracción de datos, la escalada de privilegios, la delegación no autorizada, los documentos engañosos, los archivos maliciosos, las herramientas comprometidas y los intentos de manipular la interfaz de aprobación. Las pruebas deben parecerse al uso real y no limitarse a una instrucción de laboratorio.
La cuarta debe examinar los factores humanos. ¿La interfaz lleva a aprobar sin leer? ¿Las advertencias son tan frecuentes que dejan de servir? ¿Puede el usuario distinguir entre una respuesta generada, una respuesta recuperada y una respuesta verificada? ¿Entiende qué puede hacer el agente cuando lo autoriza? Un sistema técnicamente seguro puede producir resultados inseguros si su interfaz enseña a ignorar la incertidumbre.
Los resultados deben comunicarse con mayor precisión que una afirmación general de que el sistema es seguro. Las organizaciones deben explicar el alcance de la prueba, la versión evaluada, las tareas incluidas, las categorías de falla y las limitaciones de la evidencia. Los compradores no necesitan todos los detalles internos, pero sí información para comparar sistemas y decidir si un despliegue coincide con su tolerancia al riesgo. La transparencia sobre un desconocido vale más que una promesa segura que nadie puede auditar.
Seguridad y confiabilidad están convergiendo
Cuando los agentes obtienen acceso a herramientas, la separación entre seguridad y confiabilidad se vuelve menos útil. Una inyección de instrucciones puede convertirse en un incidente de ciberseguridad si provoca que el agente revele credenciales o modifique un registro productivo. Un conector comprometido puede convertirse en un incidente de seguridad del sistema si el agente utiliza datos manipulados para tomar una decisión relevante. Un error del modelo puede convertirse en una vulneración de privacidad si expone información fuera del propósito autorizado.
Esta convergencia cambia el trabajo de los equipos de seguridad. Necesitan visibilidad sobre las identidades de los agentes, los tokens, las llamadas a herramientas, los flujos de datos y el comportamiento durante la ejecución. También deben comprender las fallas de los modelos, porque los controles convencionales de red pueden no revelar que un agente siguió una instrucción maliciosa escondida en un documento. A su vez, los equipos de producto deben comprender la gestión de identidades, los secretos, el aislamiento, la respuesta a incidentes y el desarrollo seguro.
Una respuesta práctica es asignar una identidad técnica distinta a cada agente en lugar de permitir cuentas compartidas. La identidad debe asociarse con una persona responsable, un propósito, un ciclo de vida y un conjunto de permisos. Cuando sea posible, el acceso debe otorgarse mediante tokens de corta duración. Las herramientas sensibles deben requerir una señal más fuerte que una solicitud generada por un modelo. Las acciones de alto riesgo deben limitarse y monitorearse para detectar patrones inusuales, como un aumento repentino de descargas o llamadas a dominios desconocidos.
El aislamiento también importa. Un agente que ejecuta código debe hacerlo en un entorno controlado, con red restringida, almacenamiento desechable y límites de recursos. Uno que navega necesita un contexto controlado y una forma de distinguir fuentes confiables de contenido no confiable. Uno que modifica registros debe usar fronteras transaccionales, reglas de validación y una vista previa del estado resultante. Estos controles facilitan el razonamiento sobre el sistema y la recuperación cuando algo falla.
La respuesta a incidentes debe incluir un procedimiento específico para agentes. La organización debe saber cómo suspender una ejecución, revocar credenciales, conservar registros, identificar los datos afectados, notificar a las personas responsables y restaurar los sistemas. También debe distinguir una alucinación del modelo de una falla de herramienta, una brecha de política o una intervención maliciosa. Cuanto más rápido se realice esa distinción, mejor podrá contenerse el evento y mejorarse el sistema.
La gobernanza es un ciclo de vida
La gobernanza suele presentarse como un comité que aprueba un proyecto de IA una sola vez. Ese modelo no corresponde a sistemas que aprenden de la retroalimentación, se conectan con herramientas cambiantes u operan entre distintos equipos. La gobernanza debe entenderse como un ciclo que comienza con la definición del caso de uso, continúa con la contratación y el despliegue, y permanece activo durante la operación, la modificación y el retiro.
Al principio, el equipo debe redactar una declaración breve de propósito. Debe identificar el problema, los usuarios, las personas afectadas, el beneficio esperado y las decisiones que permanecen en manos humanas. También debe señalar los usos excluidos. Esta declaración se convierte en un punto de referencia para preguntas posteriores. Si el sistema adquiere capacidades que no aparecen en el propósito original, el cambio debe iniciar una nueva revisión y no tratarse como un detalle menor de configuración.
Durante la contratación, las organizaciones deben solicitar documentación del modelo y del sistema, evidencia de evaluación, procedimientos de incidentes, términos de uso de datos, políticas de actualización y compromisos de soporte. Deben preguntar qué sucede cuando cambia el modelo, cuando el proveedor tiene una interrupción o cuando se requiere exportar la información. También deben preguntar si el proveedor puede separar los datos de clientes, ofrecer registros de auditoría y apoyar los idiomas y entornos jurídicos donde operará.
Durante el despliegue deben definirse responsables. Alguien debe responder por el producto, alguien por seguridad, alguien por privacidad y alguien por los resultados de negocio. Las funciones pueden concentrarse en un equipo pequeño, pero no deben quedar implícitas. Un incidente se vuelve más difícil de manejar cuando cada participante suponía que otra persona era responsable de la decisión.
Durante la operación deben monitorearse no sólo la precisión, sino también la deriva, los patrones de acceso, las anulaciones, la frecuencia de incidentes, el tiempo de revisión y las quejas. Un sistema que conserva el desempeño de referencia mientras produce más acciones no autorizadas no es estable. Uno que se vuelve tan lento o difícil de revisar que los usuarios lo evitan tampoco está bien gobernado. Las métricas deben combinar señales técnicas y humanas.
Por último, cada agente necesita una ruta de retiro. Los tokens deben expirar, el contexto almacenado debe eliminarse o transferirse conforme a la política, las integraciones deben desactivarse y los usuarios deben saber qué flujos ya no están disponibles. Retirarlo no es un fracaso. Es una parte normal de la administración responsable del software, especialmente cuando un modelo o una herramienta terminan su vida de soporte.
La pregunta institucional
Las preguntas más difíciles sobre los agentes son institucionales, no técnicas. ¿Quién responde cuando un sistema actúa entre varias organizaciones? ¿Quién explica una decisión a la persona afectada? ¿Quién puede impugnar el resultado? ¿Qué registros deben conservarse? ¿Qué ocurre cuando un proveedor afirma que el modelo es propietario y se niega a presentar evidencia significativa? Las preguntas se vuelven urgentes cuando un agente opera en un servicio público, una industria regulada o un flujo que afecta derechos y oportunidades.
La responsabilidad debe seguir el efecto de una acción y no desaparecer dentro de una cadena de proveedores. Una empresa puede utilizar un modelo de una compañía, una recuperación operada por otra y una integración configurada por un contratista local. El usuario debe poder identificar quién tomó la decisión, quién autorizó el despliegue y a dónde dirigir una queja. Los contratos pueden distribuir responsabilidades entre proveedores, pero no deben volver invisible la responsabilidad para la persona que soporta la consecuencia.
La explicabilidad también debe ajustarse a la decisión. El usuario no siempre necesita una descripción técnica de cada capa oculta del modelo. Sí necesita una explicación clara de la información considerada, la política aplicada, la incertidumbre presente y la razón por la que se activó o no una revisión humana. En decisiones de alto impacto, la explicación debe acompañarse de una forma de corregir datos inexactos y cuestionar el resultado. La transparencia que no permite corregir se parece más a una divulgación que a una rendición de cuentas.
Las instituciones públicas enfrentan un reto adicional. Deben preservar el trato igualitario, motivar sus decisiones, proteger los archivos públicos y respetar los límites de la autoridad administrativa. Un agente puede apoyar en investigación, traducción, clasificación o atención, pero la institución debe seguir en condiciones de explicar cómo se tomó la decisión final. La automatización no debe convertirse en una manera de evitar el deber de motivar o de trasladar una responsabilidad pública a un proveedor privado.
Agencia humana y futuro del trabajo
El debate sobre los agentes suele comenzar preguntando qué empleos podrían desaparecer. La pregunta importa, pero no es suficiente. El cambio inmediato puede ser la redistribución de tareas dentro de los trabajos existentes. Una profesional puede dedicar menos tiempo a buscar, formatear o trasladar información y más tiempo a definir objetivos, revisar evidencia, negociar compensaciones y responder por una decisión. La calidad de la transición depende de si las organizaciones tratan a las personas como supervisoras y decisoras o como operadoras pasivas que aprueban resultados de una máquina.
La agencia humana es mayor cuando las personas entienden la meta, pueden inspeccionar el proceso, intervenir en momentos significativos y rechazar una recomendación sin recibir una sanción. Se debilita cuando el sistema hace difícil cuestionar una decisión, cuando las métricas premian la velocidad sobre el juicio o cuando se hace responsable a alguien de una acción que no pudo revisar de manera realista. Un despliegue responsable debe medir la productividad, pero también la capacidad de las personas para ejercer criterio.
La capacitación debe reflejar ese nuevo papel. Las trabajadoras y los trabajadores necesitan alfabetización técnica, pero también deben saber validar fuentes, reconocer incertidumbre, detectar inyecciones de instrucciones, proteger información sensible y escalar un incidente. Las jefaturas deben rediseñar los flujos para que la revisión sea posible dentro del tiempo disponible. Si un agente genera cien recomendaciones mientras una persona puede revisar diez, la organización no creó supervisión: creó una cola que terminará aprobándose sin análisis.
Los estándares profesionales también pueden cambiar. Una abogada, un ingeniero, una periodista, una docente o una funcionaria que utilice un agente debe conservar un registro claro de lo delegado y de lo que verificó de manera independiente. No se trata de prohibir la asistencia, sino de conservar el deber profesional que no puede delegarse: juzgar si un resultado es apto para el propósito y si sus consecuencias son aceptables.
Ejemplos sectoriales
En la administración sanitaria, un agente puede organizar referencias, resumir expedientes o identificar información faltante. No debe convertir silenciosamente una recomendación en una decisión clínica. El sistema necesita minimización de datos, acceso por roles, revisión de personal calificado y una separación visible entre asistencia administrativa y juicio médico. Un enrutamiento equivocado puede retrasar la atención; una inferencia errónea sobre una paciente puede causar un daño que no aparece en una estadística general de precisión.
En los servicios financieros, un agente puede vigilar transacciones, preparar análisis o redactar comunicaciones. Debe estar limitado por umbrales, separación de funciones y aprobaciones auditables. Un sistema que puede detectar actividad inusual y cerrar una cuenta sin revisión combina detección y sanción de una manera eficiente, pero difícil de impugnar. El diseño debe mantener una vía para explicar y corregir una decisión, sobre todo cuando afecta a una persona usuaria.
En la educación, los agentes pueden ofrecer retroalimentación, adaptar ejercicios y ayudar a docentes a identificar patrones. No deben convertirse en un sistema invisible de clasificación que determine oportunidades sin transparencia. Estudiantes y familias deben saber cuándo interviene una herramienta automatizada, qué información usa y cómo puede anularla una docente. Los datos educativos también tienen una vida prolongada: un registro reunido para un ejercicio no debe transformarse automáticamente en un perfil permanente.
En el trabajo jurídico, un agente puede buscar autoridades, comparar cláusulas y preparar un primer borrador. El riesgo no se limita a una cita inventada. Incluye omitir una autoridad aplicable, revelar información privilegiada, utilizar un criterio desactualizado o presentar como ley firme un argumento incierto. Las y los profesionales necesitan verificación de fuentes, control de versiones y un registro de las proposiciones que se comprobaron con materiales primarios.
En el desarrollo de software, los agentes de programación pueden reducir tareas repetitivas y ayudar a equipos pequeños a crear prototipos. Su acceso debe limitarse por repositorio, rama y entorno. El código generado debe superar pruebas, revisiones de seguridad y una revisión humana antes del despliegue. La organización debe poder explicar si un cambio fue escrito por una persona, propuesto por un agente o tomado de una fuente externa, porque el origen puede importar para la licencia, la seguridad y el mantenimiento.
En la comunicación pública, los agentes pueden traducir, resumir y adaptar mensajes para distintas audiencias. No deben publicar automáticamente afirmaciones sensibles ni crear la apariencia de un respaldo humano que no existió. El flujo de aprobación debe conservar la fuente original, las modificaciones editoriales y la versión final. Cuando un mensaje trata de una emergencia o de una decisión pública, la velocidad no debe borrar la verificación.
Por qué América Latina necesita su propia evidencia
Muchos debates sobre gobernanza de IA se basan en grandes empresas, datos en inglés e instituciones de Estados Unidos o Europa. Esas discusiones son valiosas, pero no describen completamente las condiciones de México y del resto de América Latina. Las organizaciones suelen operar con equipos pequeños, infraestructura en nubes distintas, conectividad desigual, varios marcos jurídicos y niveles diversos de alfabetización digital. Un sistema que funciona en un entorno muy estandarizado puede comportarse de otra manera cuando los datos están incompletos, los nombres varían por región o el flujo depende de registros manuales.
La evidencia local debe tratarse como un insumo de diseño y no sólo como una adaptación comercial. Las evaluaciones deben incluir uso en español y, cuando corresponda, en lenguas indígenas; procedimientos administrativos locales; patrones regionales de riesgo; pequeñas y medianas organizaciones; y las condiciones reales de acceso a servicios digitales. Personas expertas de la región deben participar en la definición de qué es un error dañino, una divulgación inaceptable o una revisión humana significativa.
México también tiene la oportunidad de construir capacidad y no limitarse a adoptar sistemas importados. Universidades, instituciones públicas, empresas y organizaciones civiles pueden crear recursos compartidos de evaluación, capacitación profesional y criterios de contratación. Un ecosistema transparente permitiría comparar proveedores por algo más que precio y marketing. También daría a desarrolladores locales un camino para crear sistemas adaptados a los idiomas, las instituciones y las necesidades económicas del país.
La soberanía digital no debe confundirse con aislamiento. El objetivo no es rechazar los modelos globales o los estándares internacionales, sino conservar la capacidad de entender, auditar y gobernar los sistemas que se utilizan localmente. Eso exige habilidades, fuerza contractual, acceso a los datos y posibilidad de cambiar de proveedor cuando una herramienta deja de servir al interés público. Una región que no puede inspeccionar sus dependencias tiene una autonomía limitada, aunque los servicios estén disponibles a bajo costo.
Hoja de ruta para el despliegue
Una organización que inicia un proyecto con agentes puede seguir una ruta gradual. Primero, elegir un caso de uso con un objetivo claro, un beneficio medible y un impacto externo limitado. Segundo, mapear los datos y las herramientas involucradas, incluidos los permisos que no son necesarios. Tercero, construir una versión de simulación que produzca planes y evidencia sin modificar el estado externo. Cuarto, probar casos ordinarios, ambiguos y adversariales con personas que conozcan el flujo real.
Quinto, incorporar puntos de aprobación para las acciones relevantes y hacer comprensible para la persona revisora la acción propuesta. Sexto, desplegarlo con un grupo pequeño, credenciales de corta duración, una persona responsable y un procedimiento de incidentes. Séptimo, monitorear indicadores técnicos y humanos: precisión, anulaciones, acciones inexplicables, tiempo de revisión, quejas, patrones de acceso y alertas de seguridad. Octavo, revisar el sistema después de cada cambio importante de modelo, herramienta o política. Finalmente, definir las condiciones para ampliar, limitar, pausar o retirar el agente.
Esta ruta es deliberadamente ordinaria. Se parece a una buena práctica de software, seguridad y gobierno porque los agentes confiables no son una categoría separada de magia. Son sistemas complejos que combinan predicción con autoridad. Su novedad vuelve más dinámicas las consecuencias, pero no elimina la necesidad de propiedad, pruebas, controles y recuperación.
La supervisión humana vuelve visibles las acciones propuestas antes de que produzcan consecuencias externas.
De las demostraciones impresionantes a la agencia confiable
La siguiente etapa de la IA no se decidirá únicamente por el laboratorio que produzca el modelo más capaz. También la definirán las organizaciones que conviertan capacidad en agencia confiable. Los sistemas más sólidos harán visibles sus fronteras: mostrarán qué sabe el agente, qué puede hacer, qué no puede hacer, cuándo su evidencia es débil y cuándo debe intervenir una persona.
El estándar es exigente, pero práctico. Las personas no necesitan un sistema que se declare infalible. Necesitan uno que pueda supervisarse, corregirse y detenerse. Las organizaciones no necesitan eliminar toda incertidumbre antes de experimentar. Necesitan relacionar el nivel de autonomía con la evidencia disponible, la importancia de la decisión y la capacidad de recuperación.
La autonomía tiene valor cuando reduce fricción sin trasladar un riesgo invisible al usuario. El objetivo no debe ser construir sistemas que imiten a las personas con tanta precisión que la responsabilidad se vuelva ambigua. Debe ser construir sistemas cuyas acciones sigan siendo comprensibles, limitadas y responsables. En una época de agentes cada vez más capaces, la confianza se medirá menos por la seguridad con la que hablan y más por la claridad con la que pueden gobernarse.
