Según el informe Cost of a Data Breach 2025, de IBM, las organizaciones tardaron en promedio 241 días en identificar y contener un incidente de seguridad — la cifra más baja en nueve años, y aun así casi ocho meses hasta que la empresa entiende lo que realmente pasó. El mismo informe incluye un dato específico sobre IA: entre las organizaciones que sufrieron un incidente relacionado con IA, el 97% admitió no tener controles de acceso adecuados en el momento en que ocurrió el problema.
El patrón detrás de esa cifra es siempre el mismo. Cuando el uso de IA ocurre en herramientas personales, fuera de los sistemas que la empresa administra, no queda nada para reconstruir después: ningún registro de quién pidió qué, con qué información, bajo qué autorización. La investigación no se vuelve difícil — simplemente no tiene material para empezar.
Para quien decide sobre tecnología, esa brecha suele pasar desapercibida en el día a día. Solo aparece el día en que alguien pregunta qué pasó, y la respuesta es "no lo sabemos".
Cuando llega el incidente, la pregunta es siempre la misma
Toda investigación de un incidente empieza con las mismas preguntas: qué pasó, cuándo y por orden de quién. El área legal pregunta para evaluar exposición. El seguro pregunta para decidir cobertura. Un regulador pregunta para decidir si hubo negligencia. Sin respuesta, la empresa no está solo mal informada — está expuesta en tres frentes a la vez.
El informe de IBM, construido con datos de 600 organizaciones que sufrieron incidentes relacionados con IA, muestra que esa exposición es hoy la regla, no la excepción: el 63% de esas organizaciones no tenía ninguna política de gobernanza de IA vigente. Sin política, tampoco suele existir el registro que una política formal suele exigir — y el resultado aparece directo en la cuenta: el uso alto de IA fuera del control de la empresa (lo que el mercado llama IA en la sombra) agregó, en promedio, US$ 670 mil al costo de cada incidente.
La guía de técnicas forenses del NIST (SP 800-86), referencia estadounidense para la investigación de incidentes de seguridad, es directa sobre el motivo: la capacidad de investigar depende de decisiones tomadas antes del incidente — qué sistemas registran eventos, con qué nivel de detalle y durante cuánto tiempo. Un entorno sin esa preparación no queda "más difícil de investigar". Queda, en la práctica, sin ninguna capacidad de investigación, porque la evidencia que sustentaría reconstruir los hechos nunca existió.
Ese es el punto que suele perderse en la conversación sobre el uso de IA en el trabajo: el riesgo no es solo el dato sensible que puede filtrarse en una conversación con un asistente personal. Es la ausencia de cualquier rastro que permita, después, decir con seguridad qué pasó y por qué.
Por qué el control común no resuelve nada
La respuesta más común de las empresas es una política de uso aceptable: un documento que dice qué se puede y qué no se puede hacer con IA. Importa, pero resuelve menos de lo que parece — porque una política no genera registro. Declara una intención; no produce un dato consultable después.
En agosto de 2024, agencias de seguridad de nueve países — lideradas por la Dirección de Señales de Australia junto con la CISA, el FBI y la NSA de Estados Unidos, además de Reino Unido, Canadá, Nueva Zelanda, Japón, Corea del Sur y Singapur — publicaron una orientación conjunta sobre el registro de eventos. La frase de apertura del documento resume bien el punto: el registro de eventos "sostiene la continuidad de las operaciones y mejora la seguridad y la resiliencia de los sistemas críticos al permitir visibilidad de la red". Nueve agencias nacionales de seguridad de acuerdo en publicar juntas una orientación sobre este tema específico es una señal clara de cuán crítico se considera — y no solo para grandes gobiernos: el principio vale para cualquier sistema que procese información sensible, incluido el uso corporativo de IA.
El problema es que la mayoría de las herramientas de IA usadas hoy dentro de las empresas no fueron diseñadas pensando en ese estándar. Un asistente en cuenta personal no informa al empleador qué acción se tomó, sobre qué documento, ni si alguien la aprobó antes de seguir adelante. La política existe en el papel; el registro no existe en ningún lado.
Lo que tiene que existir en la práctica
Un entorno de IA preparado para ser investigado se define por mecanismos verificables, no por un documento de intenciones.
Identidad corporativa, no cuenta personal. El acceso a la IA proviene del mismo directorio que controla el acceso al correo y a los sistemas internos. Eso significa que toda acción queda asociada a una persona real dentro de la empresa, y no a una cuenta que nadie más puede ver.
Acceso según el rol de cada persona. Cuando lo que cada persona y cada agente pueden hacer está definido por rol, la lista de sospechosos de un incidente nace más pequeña — y más precisa.
Aprobación humana registrada antes de acciones sensibles. Los documentos críticos pueden requerir revisión y aprobación en dos pasos, con quien escribe separado de quien aprueba, y con la decisión registrada en el momento en que se toma — no reconstruida de memoria semanas después.
Trazabilidad detallada por área del sistema. Crear un agente, aprobar un documento, cambiar un permiso, ejecutar una acción sensible: cada uno de esos eventos queda registrado con quién, cuándo y qué. Ese es exactamente el material que faltó en el 97% de los incidentes de IA sin controles de acceso adecuados que cita IBM.
Así fue diseñada Skyller: identidad proveniente del directorio de la empresa, aprobación registrada y trazabilidad como estándar desde el primer día de uso, no como una configuración adicional para después.
De la reconstrucción en minutos a la confianza de la auditoría
El beneficio más obvio de un registro completo aparece en el peor momento posible — en medio de un incidente, cuando el equipo de seguridad necesita saber, rápido, el alcance del problema. Con trazabilidad, esa reconstrucción toma minutos: buscar por persona, por documento o por período y ver exactamente qué pasó.
Pero el beneficio va más allá del día de la crisis. Una auditoría externa, una certificación de seguridad o una exigencia contractual de un cliente más grande suelen pedir evidencia de control, no solo la existencia de una política. Una empresa que puede mostrar identidad corporativa, permiso por rol e historial completo de aprobaciones atraviesa ese proceso con evidencia concreta en mano — en lugar de explicar, después del hecho, por qué el registro de ese período específico no existe.
Hay además un efecto menos comentado: cuando el equipo sabe que el entorno de IA es auditable, el uso tiende a volverse más responsable por sí solo, sin necesidad de una prohibición para lograrlo. La trazabilidad no se trata de desconfiar de quien trabaja — se trata de garantizar que, si algo necesita explicarse, la explicación existe.
Ese mismo registro también simplifica las decisiones sobre nuevas herramientas. En lugar de aprobar un sistema de IA "de confianza" y esperar que nada salga mal, el equipo de TI obtiene un criterio de evaluación objetivo: ¿el sistema registra identidad, acción y aprobación de forma consultable, o no lo hace? La pregunta es simple, y la respuesta separa rápidamente lo que está listo para uso corporativo de lo que sigue siendo una herramienta de uso individual.
Tres preguntas para llevar a la próxima reunión
Antes de asumir que la empresa está cubierta en este punto, vale la pena responder con honestidad tres preguntas junto con TI y el área legal:
- Si hoy tuviéramos que probar quién aprobó un documento que usó la IA hace tres meses, ¿podríamos hacerlo? Si la respuesta depende de preguntarle a las personas involucradas, la empresa no tiene trazabilidad — tiene memoria.
- ¿Alguien fuera del equipo de TI puede consultar ese historial sin pedir ayuda técnica? Un registro que solo el equipo de ingeniería sabe abrir no sirve para una investigación conducida por el área legal o por un auditor externo.
- ¿Cuánto tiempo tomaría reconstruir hoy lo que pasó en un incidente relacionado con IA? Si la respuesta se mide en semanas, la empresa está en el mismo punto de partida que las organizaciones que midió IBM — 241 días para entender su propio incidente.
