Gobernanza operativa de datos e IA: del piloto al seguimiento
Un recorrido práctico para aprobar soluciones de IA, evaluar RAG, resolver incidencias de datos, controlar cambios y acordar el intercambio de información.
Guía práctica · Revisada el 4 de noviembre de 2026. El recorrido y los ejemplos son propuestas de trabajo, no casos de clientes ni requisitos legales universales.
1. Un ciclo de vida con decisiones y evidencias
Empieza por una solución concreta, no por un programa que intente abarcar toda la empresa. Registra quién responde del resultado, qué datos utiliza, a quién afecta y qué decisiones puede tomar. Si solo redacta borradores, sus controles serán diferentes de los de una herramienta que ejecuta pagos.
| Fase | Quién decide | Evidencia mínima de trabajo | Condición para avanzar |
|---|---|---|---|
| Proponer | Responsable de negocio | Objetivo, uso previsto, población afectada y alternativa sin IA | Beneficio y alcance definidos |
| Evaluar | Negocio con datos, seguridad y privacidad según el caso | Inventario, riesgos, datos permitidos y evaluación del proveedor | Riesgos críticos tratados o decisión de no continuar |
| Autorizar un piloto | Persona con capacidad de aceptar el riesgo residual | Pruebas, límites, supervisión y plan de vuelta atrás | Pruebas críticas superadas y autorización registrada |
| Operar | Responsable del servicio | Indicadores, alertas, incidencias y revisión de accesos | Seguimiento activo y escalado disponible |
| Cambiar o retirar | Responsable del servicio y negocio | Impacto, nueva evaluación o cierre, accesos revocados y retención | Consumidores informados y obligaciones de conservación revisadas |
En una organización pequeña una persona puede asumir varios papeles, pero debe quedar claro quién ejecuta y quién acepta el riesgo. Antes de cada paso, registra la decisión, fecha, responsable, versión y asuntos pendientes. Si falta una evidencia crítica, pausa el avance; una puntuación media favorable no compensa un fallo grave.
Para preparar esta fase: inventario de sistemas, revisión de proveedores y supervisión humana.
2. Evaluar IA generativa y RAG antes y después de cambiar
Que una respuesta parezca convincente no demuestra que sea correcta. Prepara un conjunto de evaluación separado de los ejemplos utilizados para ajustar el sistema. Guarda la pregunta, el contexto autorizado, la fuente y versión, la respuesta esperada o criterio de aceptación y la severidad del error.
Ejemplo ilustrativo: un asistente interno de políticas de gastos podría empezar con 30 preguntas frecuentes, 10 preguntas ambiguas, 10 sin respuesta en la documentación y 10 intentos de obtener información fuera de permiso. Esta distribución sirve para un piloto; no es una muestra estadísticamente representativa ni un mínimo obligatorio.
- Recuperación: ¿encuentra la fuente vigente y respeta los permisos del usuario?
- Respuesta: ¿la afirmación coincide con la fuente, cita lo que la respalda y distingue incertidumbre?
- Abstención: ¿pide aclaración o deriva cuando no hay información suficiente?
- Seguridad: ¿rechaza instrucciones maliciosas dentro de documentos y evita revelar datos no autorizados?
- Operación: ¿cumple el tiempo y coste aceptados, y existe revisión humana para los casos previstos?
Mide cada categoría por separado. Por ejemplo, «respuestas correctas con fuente válida / preguntas respondibles evaluadas» no debe mezclar preguntas que debían rechazarse. Desglosa por idioma, tipo de usuario y caso de uso cuando el riesgo lo requiera. Un resultado alto en preguntas fáciles no demuestra equidad ni seguridad.
Define los criterios antes de ejecutar las pruebas. Una regla interna podría bloquear el piloto ante cualquier revelación no autorizada en los casos críticos ensayados. Pasar esas pruebas no garantiza ausencia de fallos: amplía el conjunto con incidentes reales, anonimiza lo necesario y repite tras cambios de modelo, fuentes o permisos. Conserva configuración, resultados y decisión de aprobación.
Continúa con validación de respuestas y calidad de datos para RAG.
3. De una alerta de datos a una incidencia cerrada
Selecciona un conjunto de datos crítico, su propietario y quién consume sus resultados. Define controles de frescura, volumen, esquema y contenido. Para cada regla guarda la población medida, fórmula, umbral, frecuencia y acción; sin destinatario ni respuesta acordada, una alerta solo añade ruido.
Ejemplo ilustrativo: el maestro diario de clientes debe llegar antes de las 08:00. Si no llega, se avisa al equipo técnico y el informe muestra la fecha de la última carga válida. Si se detectan identificadores duplicados, se aísla el lote afectado para revisión: no se borran registros automáticamente sin una regla de resolución aprobada.
- Detectar y registrar: dataset, ejecución, regla fallida, momento y registros afectados sin copiar datos sensibles innecesarios.
- Evaluar impacto: informes, procesos y sistemas de IA afectados; prioriza por consecuencias.
- Contener: bloquear un lote, advertir a consumidores o usar una alternativa aprobada.
- Corregir la causa: asigna responsable y comprueba si el error está en la captura, transformación o definición.
- Verificar y cerrar: repite el control, confirma la recuperación con el consumidor y registra cómo prevenir recurrencias.
Mide tiempo hasta detección y recuperación, recurrencias y porcentaje de reglas críticas con responsable. Analiza por severidad para no ocultar problemas graves en un promedio. Consulta las fórmulas de calidad y el dashboard por audiencia.
4. Cambiar datos, modelos y proveedores con control
Trata como cambio una nueva versión del modelo, prompt, fuente documental, permisos, esquema o proveedor, aunque el nombre comercial del servicio siga siendo el mismo. Para cada cambio registra motivo, elementos afectados, consumidores, pruebas, autorización y plan de reversión.
- Datos: revisa compatibilidad, definiciones, unidades, retención y consumidores mediante linaje y contratos de datos.
- IA: repite el conjunto de evaluación, compara regresiones por categoría y confirma límites y supervisión.
- Proveedor: revisa tratamiento de datos, subcontratación, condiciones, capacidad de exportar y procedimiento de salida.
- Retirada: informa a usuarios, revoca claves y accesos, cierra integraciones y aplica la conservación o eliminación que corresponda. No borres evidencias sujetas a conservación.
Ejemplo ilustrativo: cambiar «importe» de euros a céntimos puede mantener el mismo tipo numérico y romper un informe financiero. Una prueba de esquema por sí sola no lo detecta: añade una comprobación de significado y validación del consumidor. Los contratos de datos ayudan a dejar explícito ese acuerdo.
5. Compartir datos y acordar su uso
Antes de enviar un archivo o habilitar una API, identifica quién entrega, quién recibe, finalidad, personas afectadas, jurisdicciones y base que permite ese uso. Tener acceso técnico no significa tener permiso para entrenar un modelo o reutilizar los datos para otro fin.
Documenta campos y clasificación, usos permitidos y prohibidos, destinatarios, controles de acceso, plazo de conservación, devoluciones o borrado, gestión de incidentes y cambios. Comprueba licencias, derechos de terceros, confidencialidad y restricciones de transferencia; los compromisos contractuales deben corresponderse con lo que el sistema permite hacer.
En la UE, el Data Act aborda, entre otras materias, datos de productos conectados y cambio de servicios de tratamiento de datos. La Comisión sitúa su aplicación general el 12 de septiembre de 2025, con disposiciones específicas que deben examinarse. No sustituye al RGPD. Para otros países, revisa el marco local y las transferencias concretas en el radar regulatorio.
Una primera entrega manejable
Elige un caso y prepara cinco evidencias: ficha de uso, asignación de decisiones, conjunto de pruebas, registro de incidencias y registro de cambios. Acuerda quién las mantiene y cuándo se revisan. El objetivo inicial es poder explicar una decisión y demostrar qué se comprobó, no acumular documentos.