Seguridad
Lo que frena a la IA en una organización seria casi nunca es el modelo. Es que alguien tiene que responder por lo que el sistema lee, escribe y envía. Esta página describe cómo se diseñan esos controles, y qué queda fuera de nuestro alcance.
El principio
Nota
Un agente sin nivel de autonomía declarado es un agente que nadie autorizó.
Es más barato construir con los permisos y el registro desde el primer día que agregarlos sobre un sistema que ya funciona. Retrofitear gobernanza obliga a rehacer decisiones de arquitectura que para entonces ya tienen usuarios encima y trabajo real dependiendo de ellas.
También cambia la conversación con el área de riesgo. Un sistema sin controles declarados pide un permiso binario, y ante lo binario un comité prudente dice que no. Un sistema que llega con su alcance escrito pide permiso para algo acotado, que casi siempre se concede, y después se gana el resto con registro.
Los controles base
No son políticas generales. Son propiedades del sistema que alguien de su organización puede ir a verificar por su cuenta, sin pedirnos permiso ni creernos.
Nota
Un control que no se puede comprobar no es un control.
El sistema no modifica ni borra en los entornos de producción. La escritura no es un permiso general: se habilita flujo por flujo, sobre un destino definido, y solo después de que ese flujo demostró calidad operando en lectura.
Cómo se comprueba
Los permisos de la cuenta de servicio se listan en la consola de administración de su organización, no en un documento nuestro.
Cada agente accede a un conjunto declarado de fuentes, no a «los sistemas de la empresa». Si el alcance no se puede escribir en una frase concreta, es que todavía no está definido.
Cómo se comprueba
«Lee la carpeta de deals cerrados y el calendario corporativo, en modo lectura, con una cuenta de servicio que tiene esos dos permisos y ninguno más» es verificable. «Acceso restringido» no lo es.
El sistema puede preparar el correo completo, con sus datos, su tono y sus adjuntos. El envío es un acto humano. Ningún flujo escribe por su cuenta a un cliente, a un manager o a un inversionista.
Cómo se comprueba
El peor caso de un error deja de ser un mensaje enviado y pasa a ser un borrador que alguien descarta.
Cada consulta, cada fuente leída y cada salida producida quedan registradas. El registro no se edita ni se borra, tampoco por nosotros. Es la diferencia entre poder explicar qué pasó y tener que confiar en que no pasó nada.
Cómo se comprueba
Meses después se puede reconstruir qué información tocó el sistema en una fecha determinada y quién aprobó la salida.
No existe un permiso general para «la IA». Cada flujo tiene su escalón declarado, y subirlo es una decisión explícita de una persona con nombre, no la consecuencia de que el sistema haya funcionado bien durante un tiempo.
Cómo se comprueba
La tabla de la sección siguiente, acordada y firmada flujo por flujo antes de habilitar cada escalón.
Niveles de autonomía
Cambiar solo una de las dos es lo que produce sistemas capaces de escribir sin que nadie haya aceptado responder por ello.
| Nivel | Qué hace | Acceso | Quién firma |
|---|---|---|---|
| N0 | Sugiere | Solo lectura | La persona redacta y decide |
| N1 | Produce borrador | Lectura y escritura en borrador | La persona edita y aprueba |
| N2 | Ejecuta en alcance acotado | Escritura en sistemas definidos | Revisión por muestreo |
| N3 | Ejecuta con auditoría | Escritura en el alcance aprobado | Auditoría y alertas |
Nota
La mayor parte del valor vive en N1: el entregable completo, en estado borrador. El ahorro de tiempo es casi el mismo que en los niveles superiores, y el riesgo queda acotado a un borrador que alguien revisa antes de que tenga efecto.
Dónde viven los datos
Trabajamos en las plataformas que su organización ya tiene y bajo sus estándares de seguridad. No replicamos su información en un entorno nuestro para procesarla con más comodidad. Eso significa que los controles que usted ya paga —identidad, doble factor, políticas de retención, prevención de fuga— siguen aplicando, porque el sistema vive dentro de ellos y no al lado.
Hay una excepción que conviene decir en voz alta: cuando un flujo consulta un modelo alojado por un tercero, el texto de esa consulta llega a ese proveedor. No lo presentamos como si no ocurriera. Lo que corresponde es declarar exactamente qué sale, hacia dónde y bajo qué acuerdo comercial, y poner las alternativas sobre la mesa —un modelo desplegado en su propia nube, o un flujo que envía un extracto en vez del documento completo— para que la decisión la tome su organización con la información a la vista.
Límites
Una página de seguridad que solo afirma capacidades no informa: vende. Estas son las cuatro cosas que preferimos decir antes de una reunión y no después de un incidente.
Cardus es una firma nueva. Lo que describimos son decisiones de diseño de sistema, verificables una por una, no un sello emitido por un tercero. Si su proceso de proveedores exige una certificación formal, hoy no la cumplimos, y preferimos que lo sepa antes de invertir tiempo.
Un modelo puede producir una salida plausible y equivocada, y ninguna configuración elimina esa posibilidad. Por eso el control no es la precisión del modelo: es que la salida no tenga efecto hasta que alguien la revise, y que quede registro de quién lo hizo.
Si el flujo usa un modelo de un tercero, algo sale. Lo que sí podemos es acotarlo, declararlo y ofrecerle alternativas. Un proveedor que le asegure lo contrario sin haber mirado su arquitectura le está vendiendo tranquilidad, no seguridad.
Diseñamos dentro de sus controles; no los reemplazamos ni los auditamos. Si hay una debilidad en la gestión de identidades o en los permisos de una carpeta compartida, el sistema la hereda. Cuando la detectamos, la reportamos.
Antes de aprobar
Un comité no evalúa la IA: evalúa el riesgo de darle acceso. Preparar estas respuestas antes de construir cambia además lo que se construye, porque diseñar con el registro y los permisos desde el principio sale más barato que agregarlos después.
Esta página trata de los sistemas que implementamos dentro de su organización. El tratamiento de los datos que usted deja en el formulario de este sitio es otra cosa: Tratamiento de datos.
Siguiente paso
Su área de riesgo tiene razón en preguntar.
Si ya tienen una lista de requisitos, esa lista es el mejor punto de partida para la conversación: nos dice qué hay que diseñar antes de escribir una línea de código.
Conversemos
