Plantilla de Inventario de Modelos de IA: Registra Cada Modelo que Tu Organización Ejecuta en Producción

Los reguladores no aceptan "usamos IA" como postura de gobernanza. Quieren una lista — cada modelo, su versión, su responsable, su nivel de riesgo, quién lo validó y cuándo fue revisado por última vez. Si no puedes producir esa lista bajo demanda, tienes una brecha de cumplimiento.

Este artículo te ofrece la plantilla completa. Cópiala, adapta los nombres de campos a tus herramientas y comienza a completarla hoy.

Por Qué los Reguladores Requieren Inventarios de Modelos

Tres marcos importantes han convergido en el mismo requisito: debes mantener un registro formal de cada sistema de IA que operas.

SR 11-7 (Federal Reserve / OCC) requiere que los bancos y sus holdings mantengan documentación exhaustiva de todos los modelos utilizados en decisiones de negocio. "Modelo" se define de manera amplia — cualquier método cuantitativo que produzca estimaciones o decisiones. Eso incluye scoring crediticio, detección de fraude, chatbots usados en originación de préstamos y cualquier flujo de trabajo asistido por LLM que toque un resultado regulado.

EU AI Act Artículo 11 requiere documentación técnica para sistemas de IA de alto riesgo antes de ser colocados en el mercado o puestos en servicio. Esa documentación debe mantenerse actualizada durante todo el ciclo de vida del sistema. Para los implementadores (organizaciones que usan sistemas de alto riesgo), el Artículo 26 requiere mantener registros y realizar supervisión humana — lo cual solo es posible si sabes qué sistemas estás ejecutando.

ISO/IEC 42001 (estándar de Sistema de Gestión de IA) requiere que las organizaciones establezcan un registro de sistemas de IA como parte de su sistema de gestión de IA. La Cláusula 6.1.2 requiere explícitamente identificar los sistemas de IA y sus riesgos asociados.

Un inventario no es opcional para organizaciones sujetas a cualquiera de estos marcos. Es la base sobre la que se construye todo lo demás.

Qué Es un Inventario de Modelos (y Qué No Es)

Un inventario de modelos es un registro estructurado de cada sistema de IA/ML que tu organización opera en producción. Incluye:

• Modelos que construiste internamente
• Modelos de proveedores (incluyendo modelos accedidos vía API como GPT-4, Claude, Gemini)
• Modelos ajustados mediante fine-tuning, incluso si la base era de un proveedor
• Modelos ejecutándose on-premises y en la nube
• Modelos embebidos en software de terceros que despliegas

No es solo una lista de APIs que llamas. Si el modelo de un proveedor toma o influye en una decisión de negocio, pertenece a tu inventario — incluyendo la versión fijada, la fecha en que fue cambiada por última vez y quién es responsable del resultado si falla.

Shadow AI — modelos desplegados por equipos individuales fuera del proceso formal de adquisición — es la brecha más común. Tu inventario solo es útil si es honesto sobre lo que realmente se está ejecutando.

La Plantilla de Inventario de Modelos

Usa una fila por despliegue de modelo. Si la misma versión de modelo se despliega en dos contextos de producción separados (ej., uno para atención al cliente, otro para operaciones internas), crea dos filas.

Fila de Ejemplo Completada

Plantilla de Registro de Cambios del Modelo

Cada cambio a un modelo en producción — actualizaciones de versión, reentrenamiento, ajustes de umbral — debe registrarse. Esto es separado de tu tabla principal de inventario; el inventario muestra el estado actual, el registro de cambios muestra el historial.

Opciones de Tipo de Cambio: Actualización de versión / Ajuste de umbral / Cambio de features de entrada / Actualización de datos de entrenamiento / Migración de infraestructura / Rollback de emergencia

Cómo Completar Cada Campo

Nivel de Riesgo es el campo que la mayoría de organizaciones evalúan mal. No lo asignes basándote en complejidad técnica. Asígnalo basándote en consecuencias de fallo. Una regresión logística simple que afecta decisiones crediticias es de Alto Riesgo. Un modelo transformer sofisticado que sugiere resúmenes de reuniones internas es de Bajo Riesgo. La pregunta es: si este modelo produce algo incorrecto, ¿quién resulta perjudicado y qué tan gravemente?

Nivel de Supervisión Humana necesita coincidir con la realidad, no con la aspiración. Si tu política dice HITL pero los revisores aprueban mecánicamente el 98% de las salidas en menos de 10 segundos, documenta eso honestamente — la brecha entre política y práctica es en sí misma un hallazgo.

Versión para modelos API de terceros requiere que fijes versiones de modelo, no uses alias "latest". Si estás llamando a gpt-4 en lugar de gpt-4-0613, no sabes qué modelo estás ejecutando realmente. Fija versiones. Regístralas.

Alcance Regulatorio debe ser completado por tu equipo legal o de cumplimiento, no por ingenieros. Los ingenieros saben qué hace el modelo; el equipo legal sabe qué regulaciones aplican a esa actividad.

Mantenimiento del Inventario

Un inventario de modelos que no se mantiene es peor que no tener inventario — crea falsa confianza y activamente desorientará a los auditores.

Cadencia mínima de revisión:

• Sistemas de Alto Riesgo: trimestralmente
• Sistemas de Riesgo Medio: semestralmente
• Sistemas de Bajo Riesgo: anualmente
• Después de cualquier incidente en producción: dentro de 5 días hábiles

Disparadores para una nueva entrada de inventario (no solo una actualización a una fila existente):

• Nuevo modelo desplegado a producción
• Modelo existente aplicado a un nuevo propósito de negocio o nuevo tipo de datos
• Modelo movido de un entorno de despliegue a otro (staging a producción)

Disparadores para actualización de una fila existente:

• Cambio de versión
• Cambio de responsable
• Cambio de estado de validación
• Retiro

Errores Comunes

Tratar el inventario como un proyecto de una sola vez. Las organizaciones crean un inventario para una auditoría y luego lo dejan desactualizar. Los reguladores verifican actualizaciones recientes. Un inventario sin tocar desde hace 18 meses es evidencia de una brecha de gobernanza, no de gobernanza.

Sub-reportar shadow AI. Equipos individuales implementan herramientas de IA — integraciones de Copilot, features de IA específicos de proveedores, integraciones API personalizadas — sin pasar por el proceso formal de adquisición. Encuesta a las unidades de negocio directamente, no solo a TI. Pregunta: "¿Hay alguna herramienta de IA que tu equipo use que no sea gestionada por TI central?" La respuesta es casi siempre sí.

Confundir el modelo con el caso de uso. La misma versión de modelo (ej., GPT-4o) desplegada en dos contextos diferentes — chat de soporte al cliente vs. resumen de documentos legales internos — representa dos entradas de inventario diferentes con niveles de riesgo potencialmente diferentes, requisitos de supervisión y alcance regulatorio.

No rastrear modelos accedidos vía API por versión. "Usamos OpenAI" no es una entrada de inventario. El ID de modelo específico, la fecha en que fue fijado y cualquier actualización subsecuente son toda información requerida.

Conexión con Tu Pipeline de Datos

Las columnas del Registro de Cambios del Modelo — particularmente Tipo de Cambio, Cambiado Por y Validación Completada — se mapean directamente a la salida de un pipeline de procesamiento de datos bien instrumentado. Si tu pipeline de datos de entrenamiento rastrea cada transformación con atribución de operador y marcas de tiempo, ya tienes la materia prima para el registro de cambios. La brecha usualmente es conectar ese registro operacional al registro de gobernanza.

Ertas Data Suite genera una pista de auditoría completa e inmutable de cada paso de transformación de datos — quién lo ejecutó, cuándo, qué cambió — que alimenta directamente el Registro de Cambios del Modelo sin entrada manual.

Agenda una llamada de descubrimiento con Ertas →

Próximos Pasos

1. Exporta una lista de todos los modelos actualmente ejecutándose en tu entorno (trabaja con ML Ops y TI)
2. Asigna un nivel de riesgo a cada uno usando tu política de clasificación (o adopta el marco de tres niveles anterior)
3. Identifica responsables para cada modelo — si nadie es responsable, ese es tu primer hallazgo de gobernanza
4. Programa la primera revisión formal para todos los sistemas de Alto Riesgo dentro de 90 días
5. Implementa un proceso de notificación de cambios para que el inventario se mantenga actualizado

El inventario es la base. Fichas de modelo, documentación de validación, pistas de auditoría y respuesta a incidentes hacen referencia a él. Constrúyelo bien, y el resto de tu programa de gobernanza tendrá algo sobre lo cual sostenerse.