Redactar el paquete de seguridad para una característica de inteligencia artificial

Qué es lo que el revisor está decidiendo realmente

Una revisión de seguridad no es un juicio sobre si un modelo es preciso. Es un juicio sobre si la organización puede asumir el riesgo, y para tomar ese juicio, un revisor necesita cuatro cosas: qué datos toca el sistema, a dónde van esos datos, quién puede ver lo que produce y qué sucede cuando está equivocado. Si alguna de esas respuestas es un párrafo de tranquilidad en lugar de un artefacto, la revisión se extiende.

Nada de esto es específico de la IA. La razón por la que las características de la IA se revisan lentamente es que los equipos rara vez producen estos artefactos, porque el sistema se construyó para demostrar valor en lugar de ser descrito.

Los cinco artefactos

Un flujo de datos de una página. Cada sistema de origen, el límite que cruza, qué se transmite y si se retiene. Nombrar al proveedor de modelos como procesador de datos y declarar explícitamente si las solicitudes y salidas se retienen o se utilizan para capacitación, citando el término contractual en lugar de la página de marketing. Esta sola página resuelve la mayoría de las preguntas legales y de privacidad en una reunión.

Un registro de riesgos. Qué puede hacer mal el sistema, el daño, la mitigación y el residual. Dos columnas de una tabla. Un revisor que ve "alucinación, mitigada por citas más un camino de negación de baja confianza, residual: el usuario puede seguir actuando sobre una afirmación no citada" puede tomar una decisión. Un revisor que ve "el modelo es confiable" no puede.

Una demostración de permisos. El modelo de control de acceso, dónde se aplica la ejecución en relación con la recuperación, y una forma de mostrar que funciona. Si el filtrado ocurre después de la recuperación, dígaselo y explique por qué la fuga de clasificación es aceptable — o corríjalo. Los revisores hacen esta pregunta con más frecuencia que cualquier otra porque es la que tiene una respuesta limpia y comprobable.

Una declaración de retención y eliminación. Cuánto tiempo se almacenan las solicitudes, salidas y contexto recuperado, dónde y cómo se satisface una solicitud de eliminación. Incluya registros y conjuntos de datos de evaluación — los conjuntos de evaluación construidos a partir de datos reales son frecuentemente la copia más longeva del contenido del usuario en el edificio.

Un camino de incidentes. Quién es contactado, qué se puede desactivar y cuánto tiempo lleva. Un interruptor de capacidad que apaga la característica sin una implementación es la respuesta más fuerte disponible en una revisión, porque convierte la exposición en el peor de los casos en una ventana limitada.

Dos hábitos que acortan la revisión

Escriba estos antes del código, no antes de la revisión. El flujo de datos y el registro de riesgos son documentos de diseño; escritos después son arqueología, y contradirán la implementación en exactamente los lugares que un revisor examina.

Responda con el artefacto, no con confianza. Si la respuesta honesta a una pregunta es que el sistema puede producir una afirmación no verificable y la mitigación es un requisito de cita que aún no se aplica, dígaselo y proporcione la fecha en que se aplicará. Los revisores aprueban las mitigaciones con fechas mucho más fácilmente que los adjetivos.

Qué hacer cuando la respuesta es no

Si la revisión bloquea la característica, la pregunta útil es qué control específico cambiaría la respuesta. Eso reformula el resultado como un trabajo con alcance en lugar de un rechazo, y generalmente resulta que es uno de los cinco artefactos que falta en lugar de una objeción fundamental. Los equipos que hacen esta pregunta obtienen una segunda revisión rápidamente; los equipos que apelan obtienen una más lenta.