El futuro de la IA podría definirse por la identidad, pero el verdadero desafío es el acceso

Google News ha destacado un titular de Newsweek que plantea una afirmación contundente: el futuro de la inteligencia artificial estará definido por la identidad. Este enfoque desplaza la atención desde la inteligencia de los modelos hacia una cuestión operativa más compleja. Antes de que un agente de IA actúe, ¿quién lo autorizó, a qué puede acceder y quién sigue siendo responsable?

El argumento surge mientras los agentes de software van más allá de responder preguntas y empiezan a realizar acciones dentro de los sistemas empresariales. Pueden recuperar documentos, modificar registros, llamar a servicios externos, escribir código y comunicarse con clientes. Cada acción útil exige acceso, pero cada nuevo permiso abre otra vía para errores, manipulación o abuso.

Por tanto, la competencia emergente no se da simplemente entre modelos más inteligentes y otros menos capaces. Se da entre agentes tratados como software con controles laxos y agentes gobernados como actores identificables. Microsoft, NIST, proveedores de identidad y grupos de estándares ya están desarrollando distintas partes de ese segundo modelo.

La propuesta de Newsweek sigue siendo más amplia de lo que la evidencia disponible puede demostrar. La identidad no determinará la calidad de los modelos, los costes de inferencia ni todos los casos de uso para consumidores. Sin embargo, se está convirtiendo en la capa de control que determina si los sistemas autónomos pueden entrar en flujos de trabajo sensibles sin hacer desaparecer la responsabilidad.

Lo que realmente cambia el titular de Google News

El titular importa porque identifica una limitación de despliegue que las evaluaciones comparativas de modelos rara vez miden.

La publicación de Google News presenta el argumento de Newsweek como una previsión sobre la dirección de la IA. No anuncia un nuevo modelo, regulación ni estándar de seguridad. Su importancia radica en replantear la competencia central de la IA en torno a la acción confiable.

Los chatbots suelen operar dentro de una conversación acotada. Un agente puede interpretar un objetivo, seleccionar herramientas y ejecutar una secuencia de acciones con supervisión limitada. Esta transición convierte la identidad de una cuestión de inicio de sesión en un requisito operativo.

Una aplicación tradicional suele tener código estable, un propósito predecible y una cuenta de servicio de larga duración. Un agente de IA puede planificar distintas rutas para alcanzar el mismo objetivo. También puede responder de forma diferente cuando cambian sus instrucciones, el contexto recuperado, las herramientas disponibles o los datos circundantes.

Esa flexibilidad hace útil a un agente. También debilita las premisas que sustentan los controles de acceso estáticos.

Un empleado que abre un sistema de nóminas presenta una identidad humana vinculada a una función, un responsable, un dispositivo y un registro laboral. Una cuenta de servicio convencional suele corresponder a una aplicación conocida y a un responsable técnico. Un agente puede actuar para un usuario, para un departamento o de forma autónoma bajo una tarea programada.

Esos modos no pueden compartir de forma segura una única credencial ambigua. Un equipo de seguridad debe distinguir al usuario que solicita el trabajo, al agente que lo realiza y al sistema que emite su autoridad en tiempo de ejecución. De lo contrario, un registro de auditoría puede mostrar que se produjo una acción sin explicar la intención de quién la originó.

La gestión de identidades y accesos, conocida habitualmente como IAM, regula cómo se autentican los actores y qué recursos pueden utilizar. La identidad de los agentes de IA amplía ese modelo al otorgar a cada agente una cuenta reconocible, un ciclo de vida, un propietario y un contexto de políticas.

La diferencia va más allá de la terminología. Si diez agentes utilizan una misma credencial de empleado, los investigadores no pueden atribuir de forma fiable las acciones individuales. Si cada agente recibe privilegios amplios sobre una aplicación, la vulneración de un flujo de trabajo puede exponer sistemas ajenos a su tarea asignada.

Una identidad diferenciada crea un punto donde aplicar restricciones. Puede respaldar autorizaciones con alcance limitado, registros separados, controles de ciclo de vida y revocación de emergencia. No garantiza un comportamiento seguro, pero hace posible la aplicación de controles y la investigación.

Ese es el núcleo creíble de la tesis de Newsweek sobre la identidad en la IA. La siguiente fase de adopción empresarial depende menos de que los agentes puedan generar resultados aceptables. Depende más de que las organizaciones puedan reconocerlos, limitarlos y detenerlos.

Por qué la identidad de los agentes de IA se volvió urgente ahora

La identidad de los agentes se volvió urgente cuando los sistemas de IA obtuvieron herramientas, autoridad delegada y vías de acceso a datos operativos.

Un modelo de lenguaje aislado produce texto. Un agente que utiliza herramientas puede convertir ese texto en una acción externa. Podría enviar un mensaje, aprobar un ticket, consultar registros de clientes, modificar código o iniciar un flujo de compra.

Cada conexión transforma una respuesta del modelo en una posible decisión de seguridad. El sistema debe determinar qué agente solicita acceso, qué persona o política lo autorizó y si la acción solicitada se ajusta a esa autoridad.

NIST formalizó esta preocupación en febrero de 2026. Su documento conceptual sobre identidad describió a los agentes como sistemas de software que realizan tareas de forma autónoma mediante datos y algoritmos.

El documento se centró en la identificación, autorización, auditoría, no repudio y defensas contra la inyección de prompts. El no repudio consiste en preservar pruebas que vinculen una acción con el actor responsable. Esto se vuelve difícil cuando los agentes comparten credenciales o delegan trabajo sin una cadena rastreable.

La inyección de prompts añade otra complicación. Ocurre cuando contenido no confiable manipula las instrucciones o elecciones de herramientas de un sistema de IA. Un agente que lee una página web, correo electrónico o documento puede encontrarse con texto hostil diseñado para redirigir su comportamiento.

La identidad no impide que el modelo interprete instrucciones maliciosas. Limita lo que el agente manipulado puede hacer después. Un agente autorizado únicamente para resumir documentos no debería obtener autoridad para eliminar archivos porque un documento se lo solicite.

Por eso la autenticación por sí sola es insuficiente. La autenticación establece qué actor está presente. La autorización decide si ese actor puede realizar una acción concreta sobre un recurso específico bajo las condiciones actuales.

La autenticación humana suele basarse en contraseñas, passkeys, datos biométricos o solicitudes multifactor. Los agentes no pueden responder a esos mecanismos como las personas. Necesitan credenciales orientadas a máquinas, intercambios de tokens, atestaciones de cargas de trabajo y políticas que preserven el contexto delegado.

El tiempo también importa. Una credencial permanente genera riesgos mucho después de que termine su tarea original. Un token de corta duración puede restringir el acceso a un periodo limitado, mientras que los alcances específicos por tarea pueden limitar las operaciones permitidas.

Por tanto, la autoridad de un agente debe corresponder a su trabajo actual, no al acceso máximo que posee su operador. Un asistente de calendario necesita permisos de programación. No necesita automáticamente acceso a informes financieros, código fuente ni todas las conversaciones privadas.

La memoria complica aún más el límite. Un agente que conserva contexto previo puede combinar información procedente de sistemas separados. Cada recuperación individual puede estar permitida, mientras que el resultado combinado revela algo que ninguna fuente por sí sola expuso directamente.

Eso hace importante la procedencia de los datos. La procedencia registra de dónde proviene la información y cómo la transformó el sistema. Una arquitectura de agentes confiable necesita tanto registros de acciones como pruebas que vinculen los resultados con sus materiales de origen.

Para los trabajadores del conocimiento, este problema aparece cada vez que un asistente busca en documentos personales y produce una respuesta. Un segundo cerebro de IA bien diseñado debe preservar el contexto sin tratar todos los elementos almacenados como si fueran igualmente compartibles.

La seguridad de identidad es urgente ahora porque los agentes están cruzando límites que las interfaces de chat rara vez cruzaban. La inteligencia ya tenía consecuencias. El acceso a herramientas convierte esa inteligencia en autoridad operativa.

La competencia principal es entre acceso autónomo y acceso responsable

La división decisiva no está entre agentes y humanos; está entre autoridad imposible de rastrear y delegación responsable.

El acceso autónomo otorga a un agente permisos permanentes y le permite actuar sin que un usuario apruebe cada paso. Ese modelo respalda el trabajo programado, la supervisión, la respuesta a incidentes y las tareas administrativas repetitivas. También crea riesgos cuando los permisos sobreviven al propósito del agente.

El acceso responsable no exige una intervención humana constante. Exige que toda acción relevante mantenga una relación visible con una identidad de agente, una política rectora, un patrocinador responsable y una solicitud de origen.

La arquitectura de identidad de agentes de Microsoft ilustra este enfoque. Su documentación sobre identidad de agentes define cuentas dedicadas que identifican y autentican agentes de IA dentro de Microsoft Entra ID.

Microsoft distingue estas identidades de las cuentas humanas y las identidades de aplicaciones tradicionales. Los usuarios humanos emplean mecanismos como contraseñas y passkeys. Las identidades de aplicaciones suelen representar servicios estables con una propiedad conocida y un comportamiento relativamente predecible.

Los agentes pueden ser más temporales y numerosos. Microsoft afirma que un agente podría existir brevemente para una única tarea, mientras que los flujos de trabajo automatizados pueden crear y retirar muchas instancias. Este dinamismo dificulta la gestión convencional de cuentas.

El modelo de Microsoft otorga a un agente una identidad única y puede asociarlo con un patrocinador. Ese patrocinador registra a la persona o grupo responsable del agente. La arquitectura también admite permisos autónomos y acceso delegado en nombre de un usuario.

La delegación es el mecanismo fundamental. Pensemos en un empleado que pide a un asistente programar una reunión con un cliente. El sistema debe conservar al menos dos identidades: la del empleado que concede la autoridad y la del agente que ejecuta la solicitud.

Si el agente llama después a otro servicio, la cadena se vuelve más compleja. El sistema posterior necesita suficiente contexto para distinguir al agente del usuario. También necesita saber qué autoridad se delegó y si esa autoridad sigue siendo válida.

Las credenciales compartidas borran esas distinciones. Convierten a varios actores en una sola entrada del registro. Esto hace más difícil detectar accesos excesivos y completar las investigaciones de incidentes.

La delegación responsable mantiene las identidades separadas. El usuario sigue siendo la fuente de autoridad, mientras que el agente aparece como el software que actúa. Las políticas pueden entonces evaluar al usuario, el agente, el recurso, la acción solicitada, el dispositivo, el nivel de riesgo y la sesión actual.

Este modelo también admite distintos umbrales de aprobación. Un agente puede leer un calendario con un permiso permanente, pero el envío de archivos confidenciales podría requerir una nueva aprobación. Un pago, una eliminación o un cambio administrativo pueden activar controles más estrictos.

El mercado más amplio de seguridad de identidad para IA compite ahora por controlar estas decisiones. Los proveedores de nube pueden integrar identidades en sus plataformas. Los proveedores independientes de identidad pueden gobernar agentes en varias nubes y aplicaciones.

Los proveedores de aplicaciones también pueden crear cuentas de agentes propietarias dentro de sus propios productos. Ese enfoque simplifica el despliegue local, pero corre el riesgo de fragmentar los controles. Una empresa podría acabar con inventarios, registros y políticas de agentes separados en cada proveedor de software.

Los organismos de normalización están intentando reducir esa fragmentación. Los borradores de autorización de la OpenID Foundation de junio de 2026 abordan la aprobación, el consentimiento, la autoridad delegada, las certificaciones y las comprobaciones de riesgo antes de que se lleve a cabo una acción.

Uno de los borradores también aborda la autorización en torno a las herramientas de Model Context Protocol. Model Context Protocol, o MCP, es una interfaz común que permite a los sistemas de IA conectarse con herramientas y fuentes de datos.

La autorización estandarizada puede ayudar a los sistemas a intercambiar información de políticas sin asumir que todas las herramientas utilizan la misma plataforma interna de identidad. Esa interoperabilidad será importante cuando los agentes crucen límites organizativos o entre proveedores.

Por tanto, el acceso con rendición de cuentas representa la vía más sólida. Preserva la autonomía cuando el riesgo es limitado, al tiempo que hace visible y revocable la autoridad. La alternativa amplía las capacidades de los agentes más rápido de lo que las organizaciones pueden explicarlas o controlarlas.

La identidad es necesaria, pero no demuestra la intención

Un agente autenticado aún puede tomar una decisión perjudicial, seguir un contexto malicioso o adoptar una interpretación equivocada de un objetivo legítimo.

Esta es la limitación central de la afirmación de que la identidad definirá el futuro de la IA. La identidad responde quién o qué está actuando. No responde de forma fiable por qué el agente eligió una acción ni si esa acción coincide con la intención humana.

Un empleado válido puede cometer un error. Un servicio correctamente autenticado puede contener un defecto de software. Del mismo modo, un agente correctamente identificado puede malinterpretar una solicitud, basarse en información falsa o exponer datos mediante una herramienta permitida por otros motivos.

El comportamiento de los agentes también es no determinista. Los sistemas no deterministas pueden generar resultados diferentes a partir de entradas similares porque la generación depende de decisiones probabilísticas y de un contexto cambiante. El software estático suele seguir una ruta de ejecución más predecible.

Esa diferencia complica la autorización. Una política puede determinar que un agente puede consultar una base de datos de clientes. No puede establecer automáticamente si cada consulta generada respalda el propósito legítimo del usuario.

Cloud Security Alliance ha sostenido que la gobernanza de agentes debe tener en cuenta los datos, el contexto y las acciones posteriores. Su análisis de gestión de acceso describe el acceso de los agentes como algo distinto del IAM tradicional.

Una comprobación de permisos convencional suele evaluar un actor, una acción y un recurso. Los flujos de trabajo agénticos también requieren atención a los datos que se procesan, al contexto de la tarea y a las consecuencias de las decisiones generadas.

Supongamos que un agente de soporte puede leer registros de clientes y redactar reembolsos. El sistema de identidad puede autenticar al agente y restringirlo a la aplicación de soporte. Aun así, necesita límites de transacción, detección de anomalías, validación de resultados y aprobación humana para los casos inusuales.

El mismo principio se aplica a los agentes de programación. Una identidad única puede separar los commits de un agente del trabajo de un desarrollador. Las políticas de repositorio pueden limitar las ramas y exigir revisión. Esos controles no pueden garantizar que el código generado carezca de vulnerabilidades.

Por tanto, la identidad debe operar junto a varias salvaguardas adicionales. El principio de mínimo privilegio limita a un agente al acceso mínimo necesario. El aislamiento protege la ejecución. La validación de herramientas comprueba los argumentos antes de que se ejecuten las acciones.

La supervisión busca patrones inesperados después de concederse el acceso. Los controles de prevención de pérdida de datos restringen resultados sensibles. La aprobación humana sigue siendo adecuada cuando las consecuencias superan un umbral de riesgo definido.

Otra incertidumbre se refiere a la escala del ciclo de vida. Los agentes pueden crearse rápidamente, duplicarse o ensamblarse a partir de varios componentes. Las empresas necesitan reglas fiables para el registro, la propiedad, la expiración, la revisión y la eliminación.

Un inventario queda desactualizado si los agentes retirados conservan permisos. Un campo de patrocinador se vuelve meramente ceremonial si nadie revisa la actividad del agente. Un registro detallado pierde utilidad si los investigadores no pueden vincular los eventos técnicos con un propósito empresarial.

La delegación entre agentes crea un problema aún más difícil. Un agente puede asignar una subtarea a otro agente, que puede invocar herramientas adicionales. Cada transferencia corre el riesgo de perder la intención del usuario original o de ampliar la autoridad más allá de la solicitud inicial.

Un diseño seguro debe preservar la cadena de delegación. Debe registrar el principal iniciador, cada agente actuante, los permisos transferidos en cada paso y la política que respalda cada decisión.

Ni siquiera ese registro revela si el razonamiento del modelo fue correcto. Proporciona rendición de cuentas a posteriori y puntos de aplicación durante la ejecución. Estas capacidades reducen el riesgo, pero no hacen que las decisiones autónomas sean intrínsecamente fiables.

Esta distinción evita que el argumento de Newsweek sobre la identidad de IA se convierta en un eslogan. La identidad es fundamental porque los controles necesitan un actor identificado. Es insuficiente porque los actores identificados aún pueden actuar de forma incorrecta.

Quién afronta presión por la seguridad de identidad de IA

Las plataformas en la nube, los proveedores de software, los equipos de seguridad y los compradores empresariales afrontan ahora presión para hacer visible la autoridad de los agentes antes de que se multipliquen los despliegues.

Microsoft ha avanzado hacia un objeto de identidad especializado para agentes. Eso presiona a otras plataformas empresariales para que ofrezcan una separación comparable entre agentes, aplicaciones y usuarios.

Una plataforma que trata cada agente como una cuenta de servicio ordinaria aún puede proporcionar autenticación. Sin embargo, a los clientes podría resultarles difícil identificar actividad específica de los agentes, asignar responsabilidad humana o gestionar a escala flotas de agentes de corta duración.

Los proveedores de identidad independientes afrontan un desafío diferente. Deben dar soporte a agentes en distintas nubes, proveedores de modelos y aplicaciones empresariales. Su oportunidad reside en crear una capa de políticas compartida en lugar de otro directorio de cuentas aislado.

Los equipos de seguridad asumen la carga operativa inmediata. Necesitan un inventario preciso de los agentes, sus patrocinadores, herramientas conectadas, acceso a datos y permisos actuales. Muchas organizaciones aún tienen dificultades para gobernar identidades de máquina y cuentas de servicio convencionales.

Añadir agentes dinámicos sin mejorar esa base incrementa la proliferación de identidades. La proliferación ocurre cuando las cuentas y los permisos aumentan más rápido de lo que los equipos pueden revisar, retirar o explicar.

Los desarrolladores también afrontan nuevas responsabilidades. La autenticación no puede seguir siendo una integración añadida poco antes del lanzamiento. La arquitectura de los agentes debe decidir cómo se propaga la identidad a través de la planificación, las llamadas a herramientas, las tareas delegadas y los servicios posteriores.

La interfaz de herramientas debe solicitar autorización con un alcance limitado. Debe evitar exponer secretos permanentes directamente al modelo. Las acciones sensibles deben generar registros estructurados que los sistemas de seguridad puedan evaluar.

Los compradores empresariales pedirán cada vez más pruebas a los proveedores. Necesitan saber si cada agente recibe una identidad distinta, si se registra un patrocinador humano y si los permisos pueden revisarse de forma centralizada.

También deberían preguntar cómo gestiona el sistema la delegación. Un agente que actúa en nombre de un usuario no debería convertir silenciosamente el acceso delegado en autoridad autónoma permanente. Revocar el permiso del usuario debería afectar al acceso del agente cuando corresponda.

Los registros de auditoría necesitan suficiente detalle para reconstruir los eventos. Un registro útil identifica al usuario, el agente, la herramienta, el recurso, la acción, la hora, la decisión de autorización y el resultado. Los registros que solo anotan una cuenta de integración genérica dejan vacíos importantes.

Los trabajadores del conocimiento tienen un interés directo en estos controles. Un asistente que busca en notas, correo electrónico, transcripciones de reuniones y archivos locales puede ahorrar tiempo. También puede combinar contexto sensible de distintas fuentes.

Las herramientas de conocimiento personal deberían hacer comprensibles los límites entre fuentes. Los usuarios necesitan confiar en que un asistente recupera material relevante sin publicar silenciosamente contexto privado ni enviarlo a un destino no previsto.

Una base de conocimiento con capacidad de búsqueda se vuelve más segura cuando la recuperación y la acción externa siguen siendo permisos independientes. Encontrar un diseño confidencial no debería otorgar automáticamente autoridad para compartirlo.

Los reguladores y auditores también exigirán una atribución más clara a medida que los agentes influyan en decisiones de contratación, préstamos, salud, seguridad y finanzas. Una empresa no puede explicar un resultado adverso diciendo que un proceso de IA no identificado tomó la decisión.

Por tanto, la presión es asimétrica. Los proveedores se benefician cuando los agentes pueden conectarse rápidamente a más sistemas. Los clientes empresariales absorben las consecuencias a largo plazo del acceso excesivo, los registros ausentes y la responsabilidad poco clara.

Los requisitos de identidad pueden ralentizar el despliegue porque introducen trabajo de registro, políticas y revisión. Esa fricción no es automáticamente improductiva. Puede revelar una propiedad poco clara antes de que un agente reciba autoridad de producción.

Los lectores de Google News deberían considerar esto como el significado práctico detrás de la previsión sobre la identidad. Los sistemas ganadores no se limitarán a reconocer el nombre de un agente. Preservarán la rendición de cuentas a lo largo de toda la cadena de acciones.

Tres señales pondrán a prueba la tesis de Newsweek sobre la identidad de IA

La tesis solo gana credibilidad si los estándares de identidad producen controles aplicables en productos reales y entornos con múltiples proveedores.

La primera señal es la adopción de identidades dedicadas para agentes dentro de las plataformas empresariales. Microsoft ha documentado su modelo, pero la prueba más amplia es si los clientes utilizan identidades separadas en lugar de reutilizar cuentas de servicio.

Observe si los inventarios de agentes se convierten en funciones estándar en el software de nube, productividad, seguridad y negocio. Observe también si cada identidad incluye un patrocinador, estado del ciclo de vida, permisos e historial de auditoría específico del agente.

Un soporte generalizado en los productos reforzaría el argumento de Newsweek. Demostraría que la identidad de los agentes ha pasado del lenguaje de las conferencias a la infraestructura operativa. La dependencia continuada de cuentas compartidas lo debilitaría.

La segunda señal es la interoperabilidad entre proveedores. OpenID, IETF, NIST y otras comunidades de estándares están desarrollando componentes de autenticación, autorización, delegación e intercambio de políticas.

La cuestión importante no es cuántos borradores aparecen. Es si un agente puede transportar autoridad verificable y limitada entre productos sin exponer una credencial permanente ni perder el contexto del usuario original.

Un estándar útil debe resistir límites prácticos. Un agente creado en una plataforma debería poder solicitar acceso a otro servicio sin dejar de ser identificable. El servicio receptor debería aplicar su propia política y conservar suficiente contexto para una auditoría.

La autorización delegada interoperable reforzaría la tesis de la identidad. Las islas de identidad específicas de cada proveedor la debilitarían, porque las organizaciones seguirían careciendo de una visión coherente de la autoridad de los agentes.

La tercera señal es la evidencia de que los controles de identidad reducen incidentes relevantes. Los anuncios de productos pueden mostrar capacidad técnica, pero no establecen su eficacia.

Los compradores deberían seguir las cuentas de agentes huérfanas, los permisos excesivos, las acciones de alto riesgo bloqueadas, la exposición de credenciales y el tiempo necesario para investigar la actividad de los agentes. También deberían medir con qué frecuencia la aprobación humana evita una ejecución insegura.

Un programa de identidad exitoso debería mejorar la atribución sin hacer inutilizables a los agentes. Si toda acción de bajo riesgo requiere aprobación manual, las organizaciones sortearán los controles o abandonarán la automatización. Si las aprobaciones rara vez ocurren, es posible que el sistema aplique pocas restricciones significativas.

La arquitectura más sólida utilizará autoridad graduada. La recuperación de bajo riesgo puede avanzar bajo una política permanente. La divulgación sensible, los compromisos financieros, los cambios destructivos y la escalada de privilegios pueden activar comprobaciones más estrictas.

Ese enfoque trata la identidad como un plano de control programable. No confunde la identidad con la inteligencia, la seguridad ni la agencia moral. Ofrece a las organizaciones una base coherente para decidir qué actor de software puede realizar qué acción.

El titular de Google News refleja una transición real, pero su formulación amplia necesita esta prueba operativa. El futuro de la IA seguirá dependiendo de los modelos, los chips, los datos, las interfaces, la economía y la regulación.

La identidad definirá qué sistemas autónomos obtienen acceso a flujos de trabajo con consecuencias relevantes. La autorización determinará qué pueden hacer esos sistemas. La supervisión y la gobernanza revelarán si sus acciones siguen alineadas con la autoridad que recibieron.

Para los desarrolladores, la medida inmediata es asignar a cada agente un propietario, un propósito, un conjunto de permisos y una regla de expiración. Los compradores empresariales deberían exigir la misma evidencia a los proveedores. Los trabajadores del conocimiento deberían examinar qué asistentes solo pueden recuperar información y cuáles pueden transmitirla o modificarla.

La cuestión ya no es si un agente de IA puede completar una tarea. Pregunte si su autoridad es identificable, limitada, revisable y reversible. Ese criterio ofrece una prueba más clara que cualquier predicción generalizada que circule por Google News.