En Northbridge Health, el equipo que opera la API del modelo CareClaims Triage debe tomar decisiones justificables antes de que una actualización del modelo llegue a las operaciones de gestión de reclamaciones. La tarea consiste en fortalecer todo el ciclo de vida del modelo frente a riesgos de envenenamiento, extracción e inferencia, generando al mismo tiempo evidencias que soporten revisiones de ingeniería, de privacidad y auditorías. Una superficie de ataque es cualquier punto donde un actor puede afectar, consultar, observar o influir en el sistema del modelo. Un objetivo de control define el resultado de protección que la arquitectura debe alcanzar y la evidencia que lo demuestra.
[fuentes][/fuentes]
La API del modelo es solo un punto de exposición. Los datos de entrenamiento, los trabajos de ajuste fino (fine-tuning), las entradas en el registro de modelos, las configuraciones de despliegue, las respuestas de la API y los registros operativos conllevan implicaciones de seguridad y gobernanza. El objetivo no es recopilar todos los artefactos posibles, sino establecer una trazabilidad que vincule una decisión relevante con los datos aprobados, el comportamiento evaluado del modelo, el despliegue autorizado y el uso observado de la API.
[fuentes][/fuentes]
Una cadena de ataque contra un modelo puede comenzar en el punto de entrada de datos a la plataforma y continuar a través del lanzamiento y uso del modelo. El envenenamiento de datos de entrenamiento, el envenenamiento durante el ajuste fino y la inserción de puertas traseras (backdoors) afectan el comportamiento del modelo antes de su despliegue. La extracción del modelo, la inversión del modelo y la inferencia de pertenencia surgen cuando el comportamiento o las salidas de la API revelan más información de la que el servicio debería exponer. Cada categoría atraviesa diferentes límites de responsabilidad, por lo que un único control perimetral no puede abarcar todo el ciclo de vida.
[fuentes][/fuentes]
Para CareClaims Triage, la arquitectura debe hacer visible dónde se verifica la procedencia, dónde la evaluación bloquea el lanzamiento, dónde se restringen las solicitudes a la API y dónde se conservan las señales de uso para su revisión. Estos controles crean puntos de decisión sin asumir que una única señal demuestra actividad maliciosa. Podemos trazar la superficie de ataque y los límites de control previstos:
La ingeniería de seguridad es responsable de la integridad de las rutas de despliegue, las protecciones de API y la cobertura de detección. La ingeniería de aprendizaje automático (machine learning) se encarga de las decisiones reproducibles de entrenamiento y evaluación. La gobernanza de datos gestiona los usos permitidos de los datos, las expectativas de linaje y las normas de retención. Se requiere una aprobación conjunta cuando un cambio en el modelo afecta a los resultados de las reclamaciones o al manejo de datos sensibles. La separación de funciones es fundamental, ya que el lanzamiento de un modelo puede ser técnicamente válido y, aun así, carecer de una procedencia o autorización aceptables. [fuentes][/fuentes]
Un objetivo de control sólido especifica el resultado esperado, el responsable (dueño) de la tarea, el ámbito de aprobación y el elemento (artefacto) conservado como evidencia. La evidencia debe permitir la reconstrucción de los hechos tras un incidente, no limitarse a demostrar la existencia de un proceso. Podemos examinar los registros que vinculan una decisión sobre el modelo con sus responsables: