Riesgo y cumplimiento
Lo que pide un comité de riesgo antes de abrir los datos
Las preguntas que conviene tener respondidas antes de la reunión.
8 min de lectura
Llega un momento en todo proyecto de agentización en el que hay que sentarse con quien responde por la seguridad de la información. Esa reunión decide el proyecto, y casi siempre se llega a ella mal preparado.
El error de partida es tratarla como una presentación de la tecnología. Al comité no le interesa la arquitectura. Le interesa qué exposición nueva asume la organización y cómo se acota.
Las siete preguntas
Cambian de forma según la organización, pero el fondo es constante. Conviene llevarlas respondidas por escrito, no improvisadas.
- Qué fuentes lee el sistema, enumeradas una por una, y con qué alcance en cada una.
- Qué puede escribir, dónde, y qué no puede escribir en ningún caso.
- Quién aprueba las salidas que llegan a un tercero, y cómo se registra esa aprobación.
- Qué se guarda de cada ejecución, dónde queda y por cuánto tiempo.
- Qué pasa si el proveedor del modelo cambia sus condiciones o deja de operar.
- Cómo se revoca el acceso, en cuánto tiempo, y quién puede hacerlo sin depender del proveedor.
- Quién opera el sistema si el equipo que lo construyó ya no está.
Qué constituye una respuesta aceptable
Una respuesta aceptable es específica y verificable. "El sistema tiene acceso restringido" no lo es. "El sistema lee la carpeta de deals cerrados y el calendario corporativo, en modo lectura, mediante una cuenta de servicio con esos dos permisos y ninguno más" sí lo es, porque alguien puede ir a comprobarlo.
La segunda propiedad de una buena respuesta es que declara el límite. Un comité desconfía más de quien afirma que no hay riesgo que de quien nombra el riesgo y explica cómo lo acota. Las alucinaciones existen; lo que importa es dónde pueden aparecer y qué hay entre esa salida y una decisión.
Nota
En trabajo de inversión, una respuesta plausible pero equivocada es más peligrosa que una respuesta obviamente mala. La segunda se descarta sola. La primera pasa.
Los tres controles que más tranquilizan
De todo lo que se puede implementar, tres cosas hacen la mayor parte del trabajo en esa reunión.
La primera es el acceso de solo lectura a los sistemas de producción. Elimina de un golpe toda una familia de riesgos: el sistema no puede modificar ni borrar nada, y eso se demuestra mirando los permisos de la cuenta de servicio.
La segunda es que toda comunicación externa quede en borrador. El sistema puede preparar el correo entero, pero el envío es un acto humano. Con eso, el peor caso de un error deja de ser un mensaje a un LP y pasa a ser un borrador que alguien descarta.
La tercera es el registro que solo añade. Cada ejecución deja constancia de qué fuentes se consultaron y qué se produjo, y esa constancia no se puede editar ni borrar, tampoco por quien administra el sistema. Es lo que permite reconstruir un incidente en vez de discutirlo.
La pregunta que casi nadie prepara
La séptima de la lista —quién opera esto si el equipo que lo construyó ya no está— es la que más proyectos frena, y la que menos se anticipa.
Un sistema que solo entiende su proveedor es una dependencia, no un activo. La respuesta aceptable no es una promesa de permanencia: son runbooks, niveles de autonomía documentados y una descripción de la arquitectura que alguien más pueda tomar. Si el proveedor no puede entregar eso, el comité tiene razón en dudar.
Preparar esas siete respuestas antes de construir cambia además lo que se construye. Es más barato diseñar con el registro y los permisos desde el principio que retrofitearlos sobre un sistema que ya funciona.
La confianza no se declara: se diseña.