Respuesta directa
En pocas palabras
Una system card describe el AI Sales Copilot que realmente se despliega: interfaz, orquestación, modelos, prompts, RAG, datos, memoria, reglas, herramientas, permisos, proveedores, revisión humana, evaluaciones, controles, fallas, monitoreo y cambios. Debe identificar una versión y un alcance concretos, separar lo que el sistema observa, recomienda y puede ejecutar, enlazar afirmaciones con evidencia reproducible y explicar límites y fallback. No sustituye model cards, data cards, contratos, evaluaciones de impacto ni revisión jurídica; tampoco certifica seguridad o cumplimiento. Su función es permitir que producto, ventas, seguridad, privacidad, operaciones y dirección tomen decisiones coherentes sobre el mismo sistema.
Documenta el sistema desplegado, no solo el modelo
El comportamiento que recibe una persona no proviene de un modelo aislado. También depende del prompt de sistema, contexto recuperado, permisos, catálogo, memoria, reglas, validadores, herramientas, interfaz y decisiones humanas. Una model card puede explicar una versión del modelo; la system card debe explicar cómo esa pieza participa en un recorrido concreto y qué otras capas pueden cambiar la salida o producir un efecto.
Empieza por la pregunta que el documento debe resolver: si una versión está lista para un piloto, una cuenta, un país o una función; qué condiciones sostienen esa conclusión; y qué hechos obligan a pausarla o reevaluarla. Evita convertir la system card en una página de marketing. Una afirmación como ayuda a vender más no permite comprobar comportamiento. Una afirmación como prepara un borrador de siguiente paso a partir del contexto permitido y requiere revisión humana sí puede probarse.
Fija identidad, audiencia y decisión antes de llenar secciones
Asigna un ID al sistema y al release. Registra nombre, propietario, operador, aprobador, fecha efectiva, estado, mercado, idioma, entorno, plan, región y organizaciones incluidas. Resuelve los alias de modelos y proveedores cuando sea posible. Un nombre comercial estable puede ocultar cambios materiales en versión, retención, herramientas o política; la ficha debe permitir reconstruir la combinación activa en una fecha.
Define quién leerá cada vista. Producto necesita alcance y dependencias; ventas necesita promesas permitidas y excluidas; seguridad necesita superficies y autoridad; privacidad necesita finalidades y recorridos de datos; operaciones necesita señales, fallback y contactos; dirección necesita residual y decisión. Puedes crear una ficha interna y una pública, pero ambas deben compartir la misma identidad y no contradecirse.
Dibuja una frontera que permita seguir el recorrido completo
Representa entrada, identidad, autorización, recuperación, orquestación, modelo, validación, herramienta, persistencia, interfaz y revisión humana. Incluye CRM, catálogo, archivos, correo, Buyer Rooms, telemetría, cachés y servicios externos cuando formen parte del recorrido. Marca qué se ejecuta dentro de la organización, qué procesa un proveedor y qué queda fuera del alcance evaluado.
Añade límites de confianza y direcciones de flujo. No basta con mostrar que RAG consulta una base: especifica con qué identidad, en qué workspace, qué filtro aplica y qué ocurre si no encuentra una fuente. Un diagrama útil deja ver dónde una instrucción externa podría confundirse con autoridad, dónde una salida se convierte en escritura y dónde una persona puede detenerla antes de un efecto.
Separa tarea, recomendación, acción y autoridad efectiva
Enumera las tareas del usuario y descompón cada una en operaciones. Observar, resumir, redactar, recomendar, guardar, enviar, cambiar una etapa, aplicar un descuento y borrar un registro tienen efectos distintos. Para cada operación registra actor, objeto, datos, permiso, confirmación, reversibilidad, evidencia y alternativa manual. No atribuyas al modelo autoridad que pertenece a una API, una cuenta de servicio o una persona.
Clasifica los puntos de decisión. Una recomendación puede mostrarse sin modificar el CRM; un borrador puede guardarse sin enviarse; una escritura puede requerir un permiso y una confirmación adicionales. Si el diseño actual no ejecuta una acción, documenta esa ausencia como límite del sistema, no como función futura implícita. Cualquier ampliación de autoridad debe abrir un cambio y repetir pruebas proporcionales.
| Criterio | Pregunta de control | Evidencia mínima |
|---|---|---|
| Observar | ¿Qué puede consultar y bajo qué identidad? | Rol, filtro, fuente y prueba entre workspaces |
| Recomendar | ¿Qué decisión apoya y qué no decide? | Uso previsto, límite y revisión humana |
| Guardar | ¿Qué estado cambia y puede revertirse? | Permiso, validación, evento y rollback |
| Enviar | ¿Quién confirma destinatario y contenido? | Gate explícito, registro y cancelación |
| Administrar | ¿Quién modifica políticas y conexiones? | Mínimo privilegio, doble revisión y auditoría |
Traza datos e instrucciones como flujos diferentes
Sigue datos personales, comerciales, precios, archivos, prompts, contexto recuperado, embeddings, salidas, feedback, evaluaciones y logs desde origen hasta eliminación. Registra finalidad, categoría, propietario, región, acceso, retención y derivados. La system card resume el recorrido y enlaza las data cards; no debe copiar expedientes o secretos dentro del documento.
Traza también quién puede dar instrucciones. El prompt de sistema, la solicitud de la persona, una nota del CRM, un documento recuperado y una página externa no tienen la misma autoridad. Separa contenido de control y contenido no confiable. Documenta delimitadores, validación, filtrado, herramientas permitidas y condiciones de rechazo. Una frase dentro del prompt no reemplaza autorización, aislamiento ni validación determinista.
Registra dependencias, procedencia y concentración
Para cada modelo, API, índice, biblioteca, servicio de identidad, almacenamiento y fuente, conserva proveedor, versión, región, datos tratados, disponibilidad, límites, subencargados, soporte, cambio y ruta de salida. Distingue componente controlado por la empresa, servicio administrado y recurso compartido. Una system card del proveedor no cubre automáticamente tu configuración, datos, integraciones ni operación.
Busca dependencias comunes. Propuestas, resúmenes y seguimiento pueden usar el mismo modelo, identidad o catálogo; una falla compartida afecta recorridos que parecen independientes. Registra fallback, portabilidad y sustitución. Si una dependencia no tiene versión fija o aviso de cambio, expresa la incertidumbre y define una prueba de detección. No conviertas desconocido en compatible por comodidad.
Diseña supervisión humana alrededor de decisiones reales
Define quién revisa, qué información recibe, cuánto tiempo tiene y qué puede hacer. Una casilla de confirmación no es supervisión suficiente si oculta la fuente, el precio, el destinatario o el efecto. La persona debe poder aceptar, editar, rechazar, pedir evidencia, volver al proceso manual y reportar un problema. Registra capacitación, carga de trabajo y conflictos de interés cuando influyan en la calidad de revisión.
Coloca gates antes de efectos materiales. Confirma identidad, permisos, destinatario, moneda, precio, fuente y alcance antes de guardar, enviar o comprometer condiciones. Evita la aprobación automática por silencio o fatiga. Mide correcciones y overrides sin castigar a quien detecta un problema. Si el volumen hace imposible revisar bien, reduce automatización o alcance en lugar de declarar que existe control humano.
Relaciona cada afirmación del sistema con una prueba reproducible
Convierte capacidades y controles en afirmaciones comprobables. Para cada una registra versión, tarea, población, escenario, datos, rol, resultado esperado, método, métrica, denominador, revisor, fecha y evidencia. Separa calidad factual, fundamento, utilidad, seguridad, privacidad, latencia, costo y recuperación. Una media favorable no debe ocultar fallas críticas o segmentos sin cobertura.
Prueba el sistema integrado, no solo el modelo. Incluye fuente ausente, dato contradictorio, permiso revocado, otro workspace, prompt injection, salida fuera de formato, herramienta caída, timeout y acción bloqueada. Mantén un conjunto normal, casos límite, negativos y adversarios. La system card resume resultados y límites; el reporte de evaluación conserva detalle suficiente para repetirlos.
Explica controles por capa y evita depender de una sola barrera
Relaciona cada riesgo con controles preventivos, detectivos, correctivos y de recuperación. Incluye identidad, aislamiento, mínimo privilegio, filtrado de RAG, separación entre datos e instrucciones, esquemas de salida, validadores, allowlists de herramientas, confirmaciones, límites de tasa, monitoreo, rollback y proceso manual. Especifica cobertura, versión, propietario y última prueba.
No uses seguridad por prompt como descripción completa. Un control puede fallar por configuración, permisos, cambio de proveedor, error humano o entrada adversaria. NIST AI RMF y su perfil para IA generativa ofrecen referencias voluntarias para mapear, medir y gestionar riesgos; no son un checklist universal ni una certificación. La system card debe mostrar residual, controles pendientes y condiciones para detener el recorrido.
Integra privacidad, seguridad y obligaciones sin prometer conformidad
Resume categorías de datos, finalidades, bases o decisiones revisadas, avisos, consentimiento cuando corresponda, responsables, encargados, transferencias, regiones, retención, derechos y controles de acceso. Para particulares en México, contrasta el tratamiento real con la LFPDPPP vigente y la revisión aplicable. La system card ayuda a reunir hechos, pero no crea autorización ni reemplaza análisis jurídico.
Documenta amenazas, secretos, segregación, vulnerabilidades, incidentes, respaldos y eliminación en artefactos enlazados. Separa una ficha pública de la evidencia restringida: transparencia no exige revelar claves, configuraciones explotables o datos personales. Una afirmación omitida por seguridad tampoco puede reemplazarse por una promesa más amplia. Publica el alcance comprobable y conserva evidencia protegida para quienes toman la decisión.
Escribe fallas y fallback antes de necesitarlo
Enumera indisponibilidad de modelo, fuente vacía, catálogo vencido, precio faltante, conflicto de moneda, identidad incorrecta, permiso insuficiente, respuesta lenta, salida inválida y herramienta rechazada. Para cada caso define señal, impacto, comportamiento seguro, mensaje a la persona, responsable, tiempo de respuesta y criterio de recuperación. Fallar de forma segura puede significar abstenerse, limitarse o volver al trabajo manual.
Prueba el modo degradado y la vuelta. Confirma que no se pierdan decisiones, no se dupliquen escrituras y no reaparezcan datos retirados después de restaurar. Una ruta manual solo es fallback si las personas conocen el proceso, tienen acceso y pueden conciliar lo ocurrido. Registra RTO, RPO o límites equivalentes cuando sean relevantes, pero no copies objetivos que no representen el recorrido comercial.
Conecta monitoreo, incidentes, cambios y retiro
Define señales ligadas a los límites: corrección humana, abstención, fuente no encontrada, herramienta bloqueada, intento entre workspaces, contenido sensible, degradación por idioma, latencia y error de proveedor. Cada señal necesita fuente, criterio, ventana, responsable y respuesta. Un dashboard agregado no sustituye una alerta sobre una acción material o una frontera de datos.
Enlaza runbook, registro de riesgos, incidentes, cambios y retiro. Actualiza la ficha cuando cambien modelo, alias, prompt, fuente, regla, herramienta, permiso, región, proveedor, finalidad o población. Conserva la versión vigente durante una investigación. Al retirar una capacidad, marca sustituto, datos, identidades, integraciones y evidencia histórica; borrar una página no demuestra que el sistema dejó de operar.
Versiona la ficha y publica vistas coherentes
Mantén un historial con delta, motivo, autor, revisores, decisión, fecha efectiva y artefactos afectados. Un cambio editorial no necesita repetir todas las pruebas; una ampliación de autoridad, datos, uso o mercado sí puede invalidar la conclusión anterior. Define disparadores y evita que un enlace estable apunte silenciosamente a otra realidad sin historial.
La vista pública puede explicar propósito, funcionamiento general, supervisión, evaluaciones, límites y contacto. La vista para clientes añade configuración, regiones, responsabilidades y cambios aplicables. La interna conserva diagramas, pruebas, pendientes y runbooks restringidos. Revisa que sitio, contrato, producto, capacitación y system card describan el mismo alcance. Una discrepancia es un hallazgo, no un problema de redacción.
Aplica la system card a Cerravi sin ampliar sus capacidades
En Cerravi, Copilot reúne 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. Las monedas permanecen separadas sin una conversión aprobada. La actividad de una Buyer Room aporta contexto, pero no confirma identidad, aceptación, firma, pago ni intención.
Forecast usa reglas transparentes del CRM: no es un modelo de machine learning entrenado o calibrado y no garantiza cierres ni ingresos. Una system card de un despliegue real debe añadir proveedores configurados, datos, integraciones, regiones, permisos, evaluaciones, límites, incidentes y fallback de esa empresa. Esta guía no certifica Cerravi ni sustituye contratos, revisión técnica, de seguridad, privacidad o asesoría jurídica.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Qué es una system card de inteligencia artificial?
Es un documento versionado que describe el sistema desplegado completo: propósito, arquitectura, modelos, datos, instrucciones, herramientas, permisos, supervisión, evaluaciones, controles, límites, fallas, monitoreo y cambios. Sirve para tomar decisiones sobre un alcance concreto, no para certificar la solución.
¿Cuál es la diferencia entre una system card y una model card?
La model card se concentra en una versión de modelo o componente, sus usos, evaluación y límites. La system card cubre el recorrido integrado que recibe la persona: aplicación, orquestación, RAG, reglas, herramientas, identidad, proveedores, interfaz, revisión humana y operación. Deben enlazarse, pero una no sustituye a la otra.
¿La system card debe ser pública?
No existe una única respuesta. Puede haber una vista pública con propósito, funcionamiento, límites y contacto; otra para clientes con configuración y responsabilidades; y una interna con evidencia restringida. Las vistas deben compartir identidad y conclusiones, sin publicar secretos, datos personales o detalles explotables.
¿Cuándo debe actualizarse una system card?
Cuando cambien modelo, alias, prompt, RAG, dataset, regla, herramienta, permiso, proveedor, región, finalidad, población, interfaz o autoridad; también después de una evaluación, incidente o cambio de fallback. La cadencia periódica complementa esos disparadores, pero no los reemplaza.
¿Una system card demuestra cumplimiento o seguridad?
No. Organiza hechos, evidencia, límites y decisiones, pero no demuestra por sí sola cumplimiento, seguridad, exactitud ni ausencia de riesgos. Debe enlazar contratos, evaluaciones, pruebas y decisiones aplicables. NIST AI RMF es voluntario y una system card publicada por un proveedor es un ejemplo de su sistema, no una certificación universal.