Respuesta directa
En pocas palabras
Una model card útil identifica la versión exacta del componente o sistema, sus usos previstos y excluidos, arquitectura, evaluaciones, límites, responsables, monitoreo y cambios. Una data card documenta por separado la motivación, procedencia, composición, recolección, transformaciones, etiquetas, restricciones, calidad, acceso, conservación y mantenimiento de cada dataset. Ambas deben enlazarse con el inventario, las pruebas y la decisión de liberación; no certifican el producto ni sustituyen contratos, evaluaciones de impacto o revisión jurídica. En un AI Sales Copilot también hay que documentar reglas, RAG, herramientas, proveedores y supervisión humana, aunque no todos esos elementos sean modelos entrenados.
Trata la ficha como una interfaz de decisión, no como una presentación
Una model card nació como una forma breve de comunicar usos previstos, condiciones de evaluación y límites de un modelo. En una operación B2B, la ficha debe ayudar a responder decisiones concretas: si una versión puede entrar a piloto, qué datos puede recibir, qué recorrido cubre, qué personas deben revisar la salida, cuándo detenerla y qué evidencia sigue vigente. Si solo resume beneficios, no permite operar ni cuestionar la solución.
Define primero audiencia y decisión. Producto necesita alcance y dependencias; ventas necesita límites que no debe prometer; seguridad necesita superficies y accesos; privacidad necesita datos, finalidades y proveedores; operaciones necesita señales y fallback; dirección necesita residual y autoridad. La misma evidencia puede tener vistas distintas, pero no conclusiones contradictorias. Una ficha pública puede omitir detalles sensibles; la versión interna debe conservar referencias suficientes para reconstruir cada afirmación.
Fija identidad, versión y frontera antes de describir capacidades
Asigna identificadores inmutables al sistema, componente, modelo, prompt, política, dataset, conjunto de evaluación y release. Registra proveedor, familia, versión o alias resuelto, fecha efectiva, región, plan, endpoint, parámetros materiales y artefacto desplegado. Un nombre comercial no basta: puede apuntar a versiones distintas con ventanas, retención, herramientas o comportamiento diferentes.
Dibuja la frontera documentada. Señala qué entra y qué queda fuera: interfaz, orquestación, reglas, recuperación, memoria, modelo externo, validadores, herramientas, CRM, correo y revisión humana. La ficha de un modelo no describe por sí sola el sistema que lo rodea. A la inversa, una regla determinista o un cálculo de CRM no debe presentarse como modelo entrenado para que el documento parezca más avanzado.
Separa system card, model card, data card y registro de cambio
No intentes guardar todo en una sola página. La system card explica el recorrido completo y sus controles; la model card describe un modelo o componente evaluado; la data card conserva hechos sobre un dataset; el evaluation report contiene método y resultados; el change record explica qué cambió y por qué. El inventario enlaza las piezas y la decisión de liberación fija la conclusión para una versión y alcance.
La separación evita herencias falsas. Un modelo base puede tener una model card del proveedor, pero la empresa sigue necesitando evidencia sobre su configuración, RAG, herramientas y uso. Un dataset aprobado para evaluar una tarea no queda aprobado para entrenamiento. Un reporte favorable de una versión no cubre un nuevo prompt o proveedor. Relaciona documentos mediante identificadores, no copiando párrafos que después envejecen por separado.
| Criterio | Pregunta principal | Evidencia de enlace |
|---|---|---|
| System card | ¿Cómo funciona el recorrido completo? | Arquitectura, controles, actores y fallback |
| Model card | ¿Para qué sirve esta versión y dónde falla? | Configuración, evaluación y límites |
| Data card | ¿De dónde viene este conjunto y qué permite? | Procedencia, composición, restricciones y mantenimiento |
| Evaluation report | ¿Qué se probó y qué se observó? | Casos, métricas, revisión y resultados |
| Change record | ¿Qué alteró la conclusión anterior? | Delta, impacto, pruebas y decisión |
Escribe usos previstos, usos excluidos y condiciones de operación
Describe tarea, usuarios, decisión apoyada, idioma, mercado, canales, datos permitidos y nivel de supervisión. Un uso previsto debe ser comprobable: preparar un borrador de siguiente paso para revisión humana es más preciso que mejorar ventas. Añade precondiciones, como catálogo vigente, permisos correctos, fuente disponible, moneda conocida y confirmación humana antes de enviar o ejecutar.
Escribe también usos no cubiertos y usos prohibidos. Separa lo que no fue evaluado de lo que fue evaluado y rechazado. Indica si la solución no debe decidir empleo, crédito, salud, precio individual, sanciones o comunicación automática, según el diseño real. No uses una lista genérica: vincula cada límite con la ausencia de evidencia, un riesgo, una dependencia o una decisión. Define quién puede aprobar una ampliación y qué pruebas debe repetir.
Documenta el sistema real alrededor del modelo
Registra prompts de sistema, recuperación, fuentes, filtros de permisos, memoria, validadores, herramientas, reglas, moderación, cachés, logs y proveedores. Explica el orden y la identidad efectiva con que cada paso accede. Un resultado puede depender más de un precio desactualizado o de un filtro RAG que del modelo base. La ficha debe permitir localizar la capa responsable sin atribuir todo a la inteligencia artificial.
Incluye fallas y alternativas: modelo no disponible, fuente vacía, timeout, salida fuera de formato, herramienta rechazada, permiso insuficiente y conflicto entre CRM y documento. Describe qué se bloquea, qué se degrada, qué se muestra a la persona y cómo continúa el trabajo manual. Registra concentraciones y subencargados. Una dependencia crítica sin salida cambia la decisión aunque la evaluación funcional sea buena.
Construye la data card desde procedencia, composición y restricciones
Para cada dataset registra motivación, dueño, finalidad, fuentes, población, periodo, unidad de observación, campos, idiomas, países, formatos, volumen, faltantes, duplicados, casos raros y categorías excluidas. Describe recolección, muestreo, limpieza, deduplicación, redacción, seudonimización, generación sintética y etiquetado. Conserva consultas, manifiestos, código y parámetros cuando sean necesarios para reproducir el conjunto.
Documenta derechos, avisos, consentimientos o excepciones revisadas, licencias, contratos, restricciones de reutilización, accesos, regiones, retención y disposición según el caso. No uses procedencia desconocida como una categoría estable: abre un pendiente o excluye la fuente. Para datos personales en México, la ficha ayuda a reunir hechos, pero la LFPDPPP vigente, su Reglamento y el contexto determinan la revisión aplicable; el documento no crea por sí solo autorización.
Relaciona cada afirmación de desempeño con una evaluación reproducible
Una cifra sin población, tarea, conjunto, fecha y método no pertenece a la ficha. Registra versión evaluada, casos, criterios, métricas, denominadores, intervalos cuando procedan, revisores, instrucciones, desacuerdos y resultados por segmento relevante. Separa exactitud factual, fundamento, utilidad comercial, seguridad, privacidad, latencia y costo. No combines dimensiones distintas en un puntaje universal.
Conserva línea base y gate definidos antes de mirar el resultado. Evita contaminación entre train, validation, test y challenge. Indica qué no se probó, qué muestra fue demasiado pequeña y dónde existe incertidumbre. Si usas un evaluador automático, documenta su versión, prompt, calibración y revisión humana. La model card resume conclusiones; el reporte enlazado conserva evidencia suficiente para repetirlas.
Describe límites como condiciones observables y no como avisos vagos
Evita frases como puede equivocarse sin explicar dónde, cómo se detecta y qué hacer. Registra idiomas, sectores, formatos, longitudes, fuentes, monedas, tipos de cuenta y situaciones fuera de distribución que degradan el resultado. Distingue limitación conocida, riesgo residual, evidencia insuficiente y defecto pendiente. Añade señal, impacto posible, control, dueño y acción recomendada.
Incluye supuestos que podrían romperse: catálogo actualizado, acceso válido, identidad correcta, proveedor estable, etiquetas consistentes y revisión disponible. Fecha la conclusión. Una ausencia de incidentes no demuestra que un límite desapareció. Explica cómo reportar un caso y qué información mínima permite investigarlo sin copiar datos personales innecesarios.
Integra privacidad, seguridad y propiedad intelectual sin prometer cobertura total
Resume categorías de datos, finalidades, roles, destinatarios, regiones, entrenamiento, feedback, retención, derechos y controles de acceso. Enlaza el inventario y la evaluación de privacidad; no copies todos los datos personales en la ficha. Documenta pruebas de aislamiento entre organizaciones, filtrado de RAG, secretos, prompt injection, salida insegura, logs y eliminación. Señala excepciones y pruebas pendientes.
Registra procedencia y restricciones de contenidos, datasets, modelos y salidas. Separa propiedad del artefacto, licencia, permiso de uso y riesgo de reclamación. Una model card no resuelve por sí sola protección de datos, seguridad o propiedad intelectual. Contratos, avisos, decisiones jurídicas y pruebas técnicas siguen siendo artefactos distintos; la ficha debe enlazarlos y mostrar su vigencia.
Convierte la ficha en un contrato operativo para monitoreo e incidentes
Define señales ligadas a los límites: acceso denegado, fuente faltante, precio sin confirmar, salida descartada, corrección humana, latencia, error de proveedor, contenido sensible, cruce de workspace y herramienta bloqueada. Para cada señal indica origen, umbral o criterio, responsable, ventana, respuesta y fallback. Una métrica agregada no debe ocultar un bloqueo crítico.
Conecta la ficha con runbook, alertas, registro de riesgos, incidentes y retiro. Explica qué evidencia pausa el uso y qué autoridad permite reanudar. Conserva versiones del documento durante una investigación; editar el texto actual no debe borrar lo que el equipo creía en la fecha del evento. Al cerrar, actualiza límite, prueba, control y condición de reapertura.
Versiona la ficha junto con modelos, datos, prompts y políticas
Un cambio material puede venir de modelo, alias, prompt, fuente RAG, dataset, regla, herramienta, región, plan, subencargado, permiso o política. Mantén un grafo simple de lineage: release del sistema, versiones de componentes, datasets usados, evaluación aplicada y decisión. Un PDF sobrescrito no permite saber qué combinación estaba activa ni qué conclusión correspondía.
Define disparadores y delta mínimo. Compara cambio esperado, superficie afectada, riesgos, pruebas a repetir, rollback y fecha efectiva. No fuerces una nueva ficha completa para corregir una errata, pero tampoco escondas una ampliación de finalidad en una edición menor. Marca documentos reemplazados, conserva referencias y evita que enlaces públicos apunten silenciosamente a otra versión sin historial.
Asigna propietarios, revisores y niveles de publicación
El dueño técnico no puede validar solo todos los límites. Define contribuciones de producto, datos, seguridad, privacidad, legal, operaciones, ventas y personas usuarias según el riesgo. Registra autor, revisor, aprobador, fecha, pendientes y conflictos. Una firma confirma una decisión acotada, no que toda afirmación futura quede aprobada.
Crea vistas interna, para clientes y pública cuando resulte útil. La pública debe ser precisa sin revelar secretos, defensas explotables ni datos personales. La contractual necesita coincidir con el servicio y plan vendidos. La interna conserva dependencias, pruebas y pendientes. Si una afirmación no puede publicarse, eso no autoriza sustituirla por una promesa más amplia; expresa el alcance comprobable o declara que falta evidencia.
Prueba la ficha contra producto, configuración y comportamiento
Toma una cuenta sintética y verifica cada afirmación material: versión resuelta, región, datos enviados, permisos, fuentes, herramientas, registro, retención, rechazo y fallback. Intenta un caso permitido, uno excluido, otro workspace, dato faltante, precio sin confirmar, proveedor caído y solicitud de eliminación. Guarda esperado, observado, fecha e identidad sin exponer secretos.
Revisa también consistencia documental. La página de ventas, contrato, aviso, panel, runbook y model card no deben prometer cosas distintas. NIST AI RMF ofrece un marco voluntario para gobernar, mapear, medir y gestionar riesgos; las model cards y datasheets son patrones de documentación propuestos por sus autores, no estándares que certifiquen la solución. Usa la prueba para encontrar contradicciones, no para decorar el expediente.
Aplica el pasaporte a Cerravi sin inventar un modelo donde hay reglas
En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana. Los recorridos públicos no envían mensajes ni cambian etapas automáticamente. Las propuestas usan productos y precios disponibles; si falta un importe, se solicita confirmación. Forecast usa reglas transparentes del CRM: no es un modelo de machine learning entrenado o calibrado y no garantiza cierres ni ingresos. La documentación debe conservar esas diferencias.
Para un despliegue concreto, la empresa documenta proveedores de IA configurados, datos cargados, integraciones, región, retención, permisos, evaluaciones, usos excluidos, incidentes y salida. El paquete de liberación enlaza system card, fichas de componentes, data cards, reporte de evaluación, riesgos, cambios, aprobaciones y rollback. Esta guía no certifica Cerravi, no demuestra cumplimiento y no sustituye asesoría jurídica, contractual, de seguridad o privacidad.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuál es la diferencia entre una model card y una data card?
La model card describe propósito, usos, evaluación, límites y condiciones de una versión de modelo o componente. La data card documenta motivación, procedencia, composición, recolección, transformaciones, restricciones, calidad y mantenimiento de un dataset. Deben enlazarse, pero aprobar una no aprueba automáticamente la otra.
¿Una model card certifica que un sistema de IA es seguro o confiable?
No. Es un artefacto de transparencia y decisión cuyo valor depende de la evidencia, alcance, versión y mantenimiento. No sustituye pruebas, contratos, evaluaciones de impacto, auditorías, revisión jurídica ni controles operativos, y no convierte un marco voluntario en certificación.
¿Necesito una model card si uso un modelo de un proveedor externo?
Sí conviene documentar la configuración y el sistema propio. La ficha del proveedor puede describir el modelo base, pero no cubre necesariamente tu plan, región, prompt, RAG, herramientas, datos, permisos, supervisión, evaluaciones ni fallback. Conserva la referencia del proveedor y añade evidencia del despliegue real.
¿Qué debe actualizarse cuando cambia un prompt o un dataset?
Registra el delta, versiones afectadas, usos, riesgos, evaluaciones que deben repetirse, resultado, aprobación y fecha efectiva. Actualiza los enlaces de lineage entre release, prompt, dataset, modelo y reporte. Una modificación menor no siempre exige rehacer todo, pero un cambio material no debe esconderse como edición documental.
¿Cerravi usa un modelo predictivo para Forecast?
No según sus límites públicos actuales. Forecast usa reglas transparentes y datos registrados en el CRM: no es un modelo de machine learning entrenado o calibrado y no garantiza cierres ni ingresos. Los proveedores que una empresa conecte a otras funciones deben documentarse según su configuración real.