Hay una diferencia importante entre "hacer preguntas" sobre un proyecto de IA y "pedir documentos" antes de aprobarlo. Las preguntas se responden de palabra, en una reunión, y se olvidan. Los documentos quedan, se pueden auditar después y obligan a quien propone el proyecto a poner por escrito algo que, muchas veces, no se había parado a pensar del todo. Ya hemos hablado de las preguntas que debe hacerse el responsable legal y compliance antes de invertir en IA; este artículo va un paso más allá y se centra en el momento concreto de la aprobación: qué entregables debería exigir compliance, por escrito, como condición para dar luz verde, no como una conversación informal de pasillo.
Un aviso importante antes de entrar en la lista: esto no es asesoría legal. MG Solutions no sustituye a un abogado ni a un delegado de protección de datos, y las cuestiones normativas concretas de tu proyecto, sobre todo si tocan datos sensibles o sectores regulados, conviene consultarlas con un profesional que conozca el detalle de tu caso.
El registro del caso de uso, con su nivel de riesgo indicado
Antes de aprobar nada, compliance debería tener sobre la mesa un documento breve que describa qué va a hacer exactamente el sistema, qué decisión toma o qué tarea ejecuta, y sobre todo, qué impacto tiene esa decisión sobre una persona real (un cliente, un empleado, un candidato). No es lo mismo un sistema que redacta borradores que revisa una persona, que uno que decide de forma autónoma si se aprueba o se rechaza algo. Pedir que esta clasificación de riesgo conste por escrito, y no solo se comente verbalmente, obliga a quien propone el proyecto a pensarlo con rigor antes de defenderlo ante compliance.
La evaluación de impacto sobre datos personales, si aplica
Si el sistema va a procesar datos personales, sobre todo si son de categorías especiales (salud, origen, afiliación) o si implica decisiones automatizadas con efectos relevantes sobre las personas, compliance debería pedir una evaluación de impacto documentada, no una afirmación genérica de que "cumple con el RGPD". Esta evaluación debería identificar qué datos se tratan, con qué finalidad, durante cuánto tiempo se conservan y qué medidas de seguridad los protegen. Si tu empresa no tiene claro cuándo hace falta este tipo de evaluación, conviene consultarlo con un especialista en protección de datos antes de avanzar; puedes encontrar contexto adicional en necesitas un DPO si usas agentes de IA en tu empresa.
Las cláusulas contractuales ya negociadas con el proveedor, no prometidas
Un error frecuente es aprobar un proyecto sobre la base de lo que el proveedor "ha dicho que va a incluir" en el contrato, en lugar de sobre el contrato ya redactado. Compliance debería pedir el borrador de contrato, con las cláusulas de tratamiento de datos, responsabilidad ante fallos y jurisdicción ya incorporadas, no una promesa verbal de que "eso se añade después". Las cláusulas mínimas que no deberían faltar en un contrato de este tipo están detalladas en qué cláusulas no deberían faltar en un contrato de agente de IA, un buen documento de referencia para contrastar lo que ofrece cada proveedor concreto.
El plan de supervisión humana
Para cualquier sistema con autonomía relevante, compliance debería exigir un documento (aunque sea de una página) que explique cómo se supervisa lo que hace el sistema una vez está en marcha: quién revisa una muestra de sus decisiones, con qué frecuencia, y qué pasa cuando se detecta un error. Un proyecto que no puede explicar cómo se va a vigilar a sí mismo una vez desplegado no está listo para producción, por buena que sea la demo inicial.
El criterio de clasificación normativa, si el sector está regulado
Si la empresa opera en un sector con normativa específica (financiero, sanitario, jurídico, seguros), compliance debería pedir que el proyecto incluya un análisis, aunque sea breve, de si el uso previsto entra en conflicto con alguna obligación sectorial concreta. De nuevo, esto no es algo que MG Solutions pueda resolver por ti: es trabajo de un asesor legal especializado en tu sector, y el coste de esa consulta es mucho menor que el de descubrir un problema normativo después de estar en producción.
El plan de reversión
Por último, y esto se olvida con frecuencia, compliance debería pedir un plan concreto de qué pasa si el sistema hay que apagarlo: cómo se revierte al proceso anterior, qué pasa con los datos ya procesados, y cuánto tiempo tardaría la empresa en volver a funcionar sin el sistema si hiciera falta. Un proyecto que no tiene pensada su propia reversión suele ser un proyecto que nadie se atreve a apagar aunque debiera, precisamente porque nadie sabe cómo hacerlo sin causar un problema mayor.
Cómo usar esta lista en la práctica
No hace falta convertir esto en un proceso pesado. En una pyme, estos seis documentos pueden caber en una carpeta compartida de cinco páginas en total, revisada por una sola persona con criterio de compliance (interna o externa) antes de dar el visto bueno. Lo importante no es el volumen de papel, es que cada uno de estos puntos se haya pensado y quede constancia de ello, en lugar de asumirse por optimismo. Si algún punto no puede documentarse con claridad, esa es precisamente la señal de que el proyecto no está listo para aprobarse todavía, aunque el resto del negocio tenga prisa por avanzar.
Conclusión
Pedir documentos concretos, en lugar de conformarse con respuestas verbales, es lo que separa una aprobación de compliance con criterio real de un trámite que solo existe para no bloquear al departamento que empuja el proyecto. Las seis piezas de esta lista —caso de uso clasificado, evaluación de impacto, contrato cerrado, plan de supervisión, análisis normativo sectorial y plan de reversión— cubren la mayoría de los riesgos que después se lamentan no haberse revisado a tiempo.
En MG Solutions ayudamos a estructurar este tipo de checklist de aprobación adaptado al tamaño y al sector de cada empresa, siempre en coordinación con vuestro asesor legal para lo que requiera criterio jurídico específico. Reserva una primera reunión y lo revisamos juntos.