Pliego de condiciones para un proyecto de IA: plantilla operativa

Un pliego útil para un proyecto de IA es un contrato de aceptación, no una lista de herramientas. Expone el problema empresarial y la situación observable de partida, el proceso incluido, las exclusiones expresas, las entradas permitidas y las fuentes autorizadas. Define la salida esperada y las pruebas que permiten aceptarla. También identifica a quien aprueba el resultado, las evidencias y registros que deben conservarse, los casos que detienen el proceso y la persona responsable del documento. La última parte fija una fecha de revisión y una decisión clara: desplegar, revisar o parar. Así, un proveedor puede proponer la ejecución sin cambiar a escondidas el significado del éxito.

¿Por qué conviene escribir un contrato de aceptación?

Una relación de modelos, conectores y funciones describe una compra, pero no aquello que el proyecto debe demostrar. El contrato coloca primero el resultado observable. El área de negocio, el equipo técnico y el proveedor reciben el mismo límite para examinar la entrega.

No hace falta anticipar toda la implementación. Sí hace falta dejar visibles los desacuerdos. Una entrada prohibida queda escrita. Si dos fuentes autorizadas se contradicen, el caso se detiene. Una salida sujeta a aprobación sigue siendo un borrador, por acabada que parezca la pantalla.

El NIST AI Risk Management Framework es voluntario y busca ayudar a incorporar consideraciones de confiabilidad al diseño, desarrollo, uso y evaluación de sistemas de IA. Su núcleo emplea Govern, Map, Measure y Manage. El Playbook propone acciones voluntarias y no es una lista de control ni una secuencia obligatoria. Esta plantilla editorial es independiente y no afirma certificación, cumplimiento ni suficiencia jurídica.

¿Cuáles son las siete partes que se pueden copiar?

Copia estos siete títulos y exige una respuesta concreta debajo de cada uno. Una respuesta vacía, vaga o discutida indica que ese punto todavía no puede aceptarse.

1. Problema y situación inicial observable. Describe el problema sin nombrar una solución. Registra qué se observa hoy y cómo se observará lo mismo durante la revisión.
2. Proceso incluido y exclusiones. Nombra el evento inicial, el punto final, las personas o sistemas implicados y todo lo que el proyecto no debe hacer.
3. Entradas permitidas y autoridad. Lista formatos y repositorios. Indica qué fuente prevalece y exige una parada si no hay autoridad o las fuentes se contradicen.
4. Salida y criterios de aceptación. Fija campos, estructura, idioma, referencias, contenido prohibido y condiciones de aprobación o rechazo.
5. Conjunto de pruebas. Incluye casos normales, incompletos, ambiguos, contradictorios y sensibles, cada uno con su resultado esperado.
6. Aprobación, fallo, parada y evidencias. Nombra el punto de decisión y la vía de parada. Indica qué versiones, fuentes, decisiones, excepciones y correcciones se guardan.
7. Responsable y revisión. Asigna el mantenimiento de reglas, fuentes y pruebas, fija una fecha y registra una decisión: desplegar dentro del límite probado, revisar o parar.

La guía práctica de France Num recomienda formalizar objetivos, funciones y reglas, probar antes del despliegue, mantener supervisión humana en tareas sensibles, asegurar la trazabilidad y conservar instrucciones, configuración y documentos. Es una orientación práctica, no una norma jurídica vinculante.

¿Qué tabla sirve como documento de trabajo?

Una fila equivale a una decisión que debe dejar evidencia verificable. Añade el detalle propio del proyecto, sin sustituir pruebas por adjetivos.

¿Cómo se prepara el conjunto de pruebas?

Prueba el límite y la negativa, no solo el caso normal bien presentado. Cada caso contiene una entrada, el resultado o parada esperado, el resultado real, el revisor y su decisión.

• Normal: entrada completa, permitida y respaldada por una fuente autorizada.
• Incompleto: falta un dato o una fuente; el proceso señala el hueco y no lo inventa.
• Ambiguo: hay más de una lectura; se solicita criterio humano.
• Contradictorio: las fuentes discrepan; se muestra el conflicto y se para.
• Sensible: el caso pertenece a la categoría sensible indicada o queda fuera del alcance; no hay acción no autorizada.

Cuando se tratan datos personales, la CNIL articula el trabajo en torno a definir la finalidad, establecer responsabilidades y base jurídica, proteger los derechos de las personas, minimizar y controlar los datos y aplicar medidas de seguridad. Estos proyectos requieren una revisión jurídica y de privacidad adecuada; la plantilla no es asesoramiento jurídico ni demuestra cumplimiento del RGPD.

¿Cómo queda un ejemplo ficticio completo?

Este flujo interno de enrutamiento de solicitudes es hipotético y no promete productividad. Solo enseña cómo rellenar las siete partes.

1. Problema y referencia. Las solicitudes internas llegan a un buzón compartido. Una muestra fechada guarda el texto, la categoría elegida por una persona y el equipo de destino.
2. Alcance. Empieza con una solicitud interna y termina con una propuesta de ruta. No responde, modifica registros, asigna trabajo ni procesa solicitudes externas.
3. Entradas. Se permiten el texto, la lista vigente de categorías y el directorio aprobado. El directorio manda sobre los destinos. Si falta una categoría o un destino, se para.
4. Salida. El borrador contiene identificador, categoría y destino propuestos, entrada citada del directorio y motivo breve. Solo se acepta si todos los campos están y las fuentes respaldan la propuesta.
5. Pruebas. Se incluyen una petición clara de instalaciones, otra sin ubicación, una frase que puede referirse a acceso o equipo, fuentes que apuntan a equipos distintos y una petición marcada como sensible. Se espera, respectivamente, borrador, parada por dato ausente, juicio humano, parada por conflicto y parada sensible.
6. Aprobación y evidencia. La persona coordinadora acepta, edita o rechaza. Los casos incompletos, ambiguos, contradictorios, sensibles o externos no se enrutan. Se guardan versiones, borrador, decisión, excepción y corrección.
7. Responsable. Operaciones mantiene categorías, directorio y pruebas. La revisión fechada decide desplegar dentro del límite, revisar o parar.

Este artefacto es más concreto que el ejemplo general de proyecto de inteligencia artificial. Para elegir antes el proceso, consulta cómo automatizar una empresa con IA.

¿Qué señales delatan una lista de deseos?

El pliego falla cuando conoce el producto, pero no sabe cómo aceptar el resultado.

• empieza por una plataforma y no por el problema;
• abarca un departamento entero sin exclusiones;
• habla de «datos de empresa» sin fuentes ni autoridad;
• pide calidad sin formato ni criterios;
• solo prueba ejemplos favorables;
• menciona revisión humana sin revisor ni punto de decisión;
• solicita registros sin indicar qué evidencia conservar;
• no define paradas ni entrega a una persona;
• nadie mantiene fuentes, pruebas y fecha de revisión.

¿Cuándo se despliega, revisa o para?

La puerta de decisión es breve porque la evidencia ya está definida.

• Desplegar: las pruebas dejan resultados inspeccionables, se cumplen los criterios, las paradas funcionan, existe aprobación humana y el responsable acepta solo el alcance probado.
• Revisar: el problema sigue vigente, pero falta una regla, entrada, fuente, criterio, prueba o ruta de aprobación. Se cambia el contrato y se vuelve a probar.
• Parar: no pueden establecerse las entradas o su autoridad, la salida no puede juzgarse, la parada falla o nadie asume la responsabilidad.

Desplegar no autoriza ampliar el alcance. Una entrada, fuente, salida o acción nueva cambia el contrato y exige pruebas y revisión.

Preguntas frecuentes

¿Cómo se redacta un pliego para un proyecto de IA? Como un contrato de aceptación: referencia, alcance, exclusiones, entradas, salida, pruebas, aprobación, paradas, evidencias, responsable y revisión.

¿Qué componentes debe incluir? Siete partes: problema; alcance; fuentes; salida; pruebas; aprobación, paradas y evidencias; propiedad y revisión.

¿Cuáles son las etapas? Redactar, preparar casos, probar dentro del alcance, revisar evidencias y decidir entre desplegar, revisar o parar. Es una recomendación editorial.

¿Demuestra cumplimiento legal? No. Según la CNIL, los proyectos con datos personales necesitan una revisión jurídica y de privacidad adecuada.