AI Gobernanza antes de la Serie A: las políticas que los inversores ahora esperan

1. Tratar la gobernanza de AI como infraestructura para la inversión

Una startup de AI que se prepara para una Serie A necesita evidencia de que su producto puede escalar sin perder el control de los datos, los modelos, los resultados para el cliente o las declaraciones comerciales. La gobernanza proporciona el sistema operativo para esa evidencia. Asigna derechos de decisión, define el uso aprobado, exige pruebas antes del lanzamiento, registra excepciones y da al consejo una forma de conectar la velocidad del producto con el riesgo, la caja y el valor para el cliente.

El punto de partida es el papel real de AI en la empresa. Una empresa puede entrenar un modelo, ajustar finamente un modelo de terceros, recuperar información para un modelo fundacional, desplegar un agente, integrar un servicio externo, proporcionar infraestructura o usar AI solo dentro de las operaciones. Cada papel crea dependencias y obligaciones distintas. El consejo debe documentar el resultado del producto, el límite del sistema, las personas y organizaciones afectadas, las decisiones materiales, las jurisdicciones y las partes que suministran datos, modelos, herramientas y distribución.

La gobernanza debe apoyar la ejecución. Los equipos de producto necesitan una ruta clara desde el experimento hasta el lanzamiento controlado. Los equipos comerciales necesitan un lenguaje preciso sobre capacidades, limitaciones y responsabilidades del cliente. Los compradores empresariales necesitan evidencia que cubra seguridad, privacidad, disponibilidad, rendimiento del modelo, subcontratistas, incidentes y salida. Los inversores necesitan entender si el crecimiento depende de derechos, capacidades y economía que la empresa pueda retener. Los empleados necesitan vías de escalamiento cuando el sistema se comporta fuera de su propósito aprobado.

NIST organiza la gestión de riesgos de AI mediante Gobernar, Mapear, Medir y Gestionar. ISO/IEC 42001 utiliza un enfoque de sistema de gestión para establecer, implementar, mantener y mejorar continuamente la gobernanza de AI. Estos marcos apoyan una estructura práctica para el consejo: definir la responsabilidad, comprender el contexto, producir evidencia, gestionar el riesgo residual y revisar las decisiones a medida que cambia el sistema.

El consejo debería aprobar cinco evidencias vinculadas. La evidencia de producto conecta el sistema con un resultado relevante para el cliente. La evidencia de derechos cubre datos, software, modelos y contenido. La evidencia de rendimiento cubre precisión, robustez, seguridad y monitorización. La evidencia comercial cubre aprovisionamiento, distribución, economía unitaria y declaraciones. La evidencia de gobernanza cubre responsabilidad, incidentes, regulación y cambio. Una debilidad material en una evidencia debería devolver el caso de lanzamiento o de inversión para su remediación.

Cinco evidencias vinculadas conectan la ejecución de producto con una decisión de escala controlada por el consejo.

2. Definir el sistema, el resultado y el nivel de riesgo

La gobernanza comienza con una definición precisa del sistema. La empresa debería identificar al usuario, la finalidad prevista, la finalidad prohibida, las entradas, el modelo, las herramientas, las fuentes de recuperación, la salida, la acción, la parte afectada y la persona humana responsable. Una etiqueta genérica como un asistente AI o una plataforma inteligente oculta la diferencia entre resumir información, recomendar una acción financiera, aprobar crédito, seleccionar a un candidato, diagnosticar una afección o autorizar un pago.

La definición debería mostrar si el sistema solo produce contenido o también puede invocar herramientas, modificar registros, enviar comunicaciones, mover dinero, alterar el acceso, adquirir servicios o afectar los derechos de una persona. Los sistemas agénticos requieren un mapa de herramientas disponibles, credenciales, memoria, servicios externos, puntos de control de decisiones y controles de terminación. El Marco de Gobernanza de Modelos AI para AI agéntica de Singapur hace hincapié en acotar los casos de uso y los poderes, la responsabilidad humana significativa, los controles del ciclo de vida y la responsabilidad del usuario final.

La clasificación por nivel de riesgo debería seguir la consecuencia y la exposición. La evaluación puede considerar seguridad, pérdida financiera, derechos legales, usuarios vulnerables, datos personales o confidenciales, escala, reversibilidad, autonomía, opacidad del modelo, ciberseguridad, situación regulatoria y disponibilidad de revisión humana. La empresa también debería evaluar el riesgo creado cuando varios componentes de baja consecuencia se combinan en un flujo de trabajo de mayor consecuencia.

El consejo de administración debe definir qué nivel puede aprobar un líder de producto, cuál requiere revisión de seguridad, privacidad o legal, y cuál requiere aprobación de la dirección ejecutiva o del consejo de administración. Los sistemas de consecuencias elevadas deben contar con evidencia más sólida, permisos más restringidos, pruebas independientes y reglas explícitas de parada. Los usos prohibidos deben documentarse por escrito, comunicarse y aplicarse mediante controles técnicos y contractuales.

El registro de clasificación debe estar versionado. Un cambio de modelo, una nueva fuente de datos, un nuevo grupo de clientes, una jurisdicción adicional, una mayor autonomía o un cambio en la declaración comercial pueden alterar el nivel de riesgo. Un sistema que antes se utilizaba para redactar textos internos puede necesitar una nueva gobernanza cuando empieza a responder a clientes o a ejecutar transacciones.

Tabla 1. AI definición del sistema y registro de niveles de riesgo

El nivel es una decisión de gestión respaldada por una revisión cualificada cuando esté implicada la ley o una actividad regulada.

3. Establecer la rendición de cuentas del consejo y los derechos de decisión

El consejo de administración sigue siendo responsable de la empresa incluso cuando un modelo, un proveedor o un cliente ejecuta parte del flujo de trabajo. Debe aprobar el apetito de riesgo de AI, los casos de uso materiales, el modelo de responsabilidad, la frecuencia de reporte y los umbrales de escalado. La dirección debe convertir esa orientación en responsables designados y procedimientos operativos.

La rendición de cuentas debe abarcar el resultado completo. El responsable de producto puede tener a su cargo el propósito previsto y el resultado para el cliente. El responsable del modelo puede tener a su cargo el rendimiento, la evaluación y los cambios. El responsable de datos puede tener a su cargo la procedencia, la calidad, los permisos y la retención. Seguridad puede tener a su cargo los controles de amenazas y la respuesta a incidentes. Los asesores legales y de privacidad pueden evaluar las obligaciones aplicables. El liderazgo comercial puede tener a su cargo las declaraciones y los compromisos con socios. Un patrocinador ejecutivo puede resolver conflictos y aceptar el riesgo residual dentro de la autoridad delegada.

El consejo debe evitar aprobaciones fragmentadas. Un sistema puede superar una evaluación técnica y, aun así, no superar el análisis de derechos, cliente, compras o economía. Una sola nota de lanzamiento debe conciliar toda la evidencia material y las excepciones. La nota debe indicar el uso, el nivel, la versión, los mercados afectados, las pruebas, las limitaciones, el monitoreo, los incidentes, las cuestiones abiertas, el riesgo residual aceptado, los responsables y la fecha de la próxima revisión.

Los comités deben ser proporcionales a la etapa. Una empresa pre-Serie A puede utilizar un foro semanal multifuncional de lanzamiento respaldado por una revisión mensual de la dirección y un reporte trimestral al consejo. El foro necesita autoridad para retener un lanzamiento, reducir su alcance o exigir remediación. Los incidentes y cambios materiales deben saltarse la frecuencia normal.

El reporte al consejo debe vincular el riesgo y el desempeño del negocio. Entre las métricas útiles se incluyen los sistemas activos por nivel, las revisiones atrasadas, los resultados de evaluación, los hallazgos de seguridad, las excepciones de derechos de datos, las quejas de clientes, las anulaciones humanas, los incidentes, la concentración de proveedores, el coste del modelo, el margen bruto y el runway de caja. El reporte debe distinguir los resultados observados de las previsiones y los escenarios de la dirección.

4. Crear un inventario de sistemas y dependencias de AI

Una empresa preparada para inversores debe conocer cada sistema AI material que desarrolla, compra, incorpora o permite usar a sus empleados. El inventario debe incluir productos en producción, configuraciones específicas de clientes, copilotos internos, experimentos conectados a datos reales, herramientas en la sombra, modelos utilizados por contratistas y funcionalidades de AI dentro de software empresarial.

Cada entrada debe identificar al responsable, el propósito, los usuarios, el nivel de riesgo, el estado, el modelo y la versión, el proveedor, el alojamiento, las categorías de datos, las jurisdicciones, las herramientas, las fuentes de recuperación, las decisiones posteriores, el control humano, las evaluaciones, el monitoreo, los incidentes, los contratos y la fecha de revisión. El inventario debe enlazar con la evidencia subyacente en lugar de convertirse en una hoja de cálculo estática desconectada de las operaciones.

El análisis de dependencias debe ir más allá del modelo identificado. Un servicio puede depender de una región de nube, una base de datos vectorial, un marco de orquestación, un filtro de contenido, una herramienta de observabilidad, un proveedor de identidad, un API externo y un almacén de datos de clientes. La empresa debe identificar qué dependencia puede cambiar el comportamiento, las condiciones, el precio, la ubicación, el acceso o la disponibilidad. Debe registrar el tiempo de sustitución y el efecto de la terminación.

Los componentes de código abierto requieren una revisión de procedencia, licencia y seguridad. Los pesos del modelo, el código de entrenamiento, los conjuntos de datos y las bibliotecas pueden conllevar licencias y obligaciones diferentes. La empresa debe registrar la versión, la fuente, la modificación, el uso permitido, la atribución, las condiciones de distribución y las vulnerabilidades conocidas. Las conclusiones sobre propiedad intelectual deben ser confirmadas por asesoría jurídica cualificada.

Los controles de inventario deben conectarse con ingeniería. Las nuevas credenciales de modelos, los paquetes, los endpoints y los despliegues en producción pueden activar el registro o la actualización. Compras puede bloquear a un proveedor no aprobado. El control de acceso puede limitar los datos sensibles a sistemas autorizados. El monitoreo puede conciliar los endpoints activos con los registros aprobados. El objetivo es una visibilidad operativa actualizada.

La evidencia se acumula desde la definición del sistema hasta el monitoreo y la retirada controlada.

5. Mapear los derechos de datos, la procedencia, la privacidad y la retención

La gobernanza de datos debe responder si la empresa tiene derecho a recopilar cada categoría de datos, acceder a ella, transformarla, combinarla, usarla para entrenamiento o evaluación, divulgarla y conservarla. Un contrato con clientes, una página web pública, una licencia de proveedor, una carga de empleados o un repositorio de código abierto no establecen automáticamente todos los derechos previstos. La empresa debe mantener un registro de finalidades y derechos para los datos de entrenamiento, los datos de evaluación, el contenido de recuperación, los prompts, las salidas, la telemetría y la retroalimentación humana.

El registro debe identificar el origen, el responsable del tratamiento o propietario, la base jurídica o autorización contractual, la finalidad, la ubicación geográfica, la sensibilidad, el acceso, el encargado del tratamiento, la conservación, la supresión y las restricciones al entrenamiento de modelos o a la reutilización. Los datos personales deben vincularse con la legislación de privacidad aplicable. Los datos confidenciales y regulados deben vincularse con obligaciones contractuales y sectoriales. Los derechos de autor, los derechos sobre bases de datos, los secretos comerciales y los derechos de imagen pueden requerir un análisis independiente.

La Ley de Protección de Datos Personales de UAE establece obligaciones para el tratamiento de datos personales y derechos para los interesados. El conjunto de herramientas de AI del ICO británico proporciona áreas de riesgo prácticas a lo largo del ciclo de vida de AI y está en revisión tras la Data (Use and Access) Act; las empresas deben revisar de nuevo las orientaciones vigentes antes de basarse en él. El Reglamento de AI de la UE, GDPR y las normas sectoriales pueden aplicarse conjuntamente. Los marcos de Arabia Saudí y Singapur también vinculan la AI responsable con la privacidad y la gobernanza de datos.

La minimización de datos debe integrarse en el diseño de productos. La empresa debe identificar los datos mínimos necesarios para el resultado aprobado, limitar el acceso, separar entornos y establecer reglas de supresión o desidentificación. Los sistemas de recuperación deben aplicar permisos a nivel de documento. Los registros de prompts y salidas deben evaluarse en busca de datos sensibles. El entrenamiento de modelos debe separarse de la prestación de servicios cuando los derechos y las expectativas de los clientes difieran.

La procedencia debe mantenerse tras la transformación. La empresa debe poder rastrear un resultado relevante hasta la versión del modelo, el prompt o la entrada, las fuentes de recuperación, la configuración de políticas y la intervención humana relevante. Esto facilita la evaluación, la corrección, la explicación al cliente, la investigación de incidentes y la diligencia debida de inversores. Cuando la trazabilidad completa no esté técnicamente disponible, la limitación debe documentarse y reflejarse en el alcance del sistema.

6. Gobernar modelos fundacionales, proveedores y componentes de código abierto

Los modelos de terceros pueden acelerar el desarrollo de productos y, al mismo tiempo, generar riesgos de concentración, precios, datos, rendimiento y continuidad. La empresa debe evaluar el proveedor, el servicio, el contrato, la ficha del modelo o la documentación técnica, las condiciones de uso de datos, la seguridad, la privacidad, el alojamiento, los subencargados, los niveles de servicio, la política de cambios, el acceso a evaluaciones, las condiciones de propiedad intelectual, las indemnizaciones, la notificación de incidentes, la terminación y la devolución o supresión de datos.

La evaluación del proveedor debe ser específica para cada caso de uso. Un modelo aceptable para redactar textos internos puede no ser adecuado para una decisión de cliente con consecuencias financieras o jurídicas. La empresa debe probar el modelo exacto, la configuración, los prompts, las herramientas, los datos de recuperación y las salvaguardas utilizados en producción. Los benchmarks de los proveedores no sustituyen la evaluación de la empresa.

La gestión de cambios de modelos es relevante. Los proveedores pueden actualizar los pesos, el enrutamiento, los filtros, los límites de contexto, los precios o las condiciones. La empresa debe saber si se puede fijar una versión, cómo funcionan los avisos previos y qué ocurre cuando una versión se retira. Un cambio relevante debe activar pruebas de regresión y una decisión de lanzamiento. Si el servicio utiliza enrutamiento dinámico de modelos, la aprobación debe cubrir la lógica de enrutamiento y todos los modelos elegibles.

La resiliencia comercial exige un plan de salida. El consejo debe comprender el esfuerzo necesario para sustituir al proveedor, exportar datos, reproducir evaluaciones, migrar prompts y herramientas, mantener el servicio al cliente y volver a aprobar el sistema. El diseño multimodelo puede reducir parte de la concentración, aunque aumenta la complejidad de integración, pruebas y costes. La elección debe basarse en la viabilidad económica verificada y en los requisitos de servicio.

Tabla 2. Registro de dependencias de modelos, proveedores y datos

Las conclusiones contractuales y legales requieren la revisión de los términos suscritos y el uso previsto.

7. Establecer controles de desarrollo, pruebas y lanzamiento

AI el desarrollo necesita una ruta reproducible desde el experimento hasta producción. La empresa debe registrar el problema, la línea base, los datos, el modelo, la configuración, el código, el conjunto de evaluación, los criterios de aceptación, el revisor, el alcance del lanzamiento y el plan de monitorización. La evidencia debe permitir que una persona cualificada entienda qué cambió y por qué se autorizó el lanzamiento.

Las pruebas deben cubrir el uso aprobado y los modos de fallo creíbles. Las medidas de rendimiento pueden incluir exactitud, precisión, exhaustividad, calibración, calidad de recuperación, respaldo factual, seguimiento de instrucciones, estabilidad, latencia y coste. Las pruebas basadas en consecuencias pueden cubrir sesgos, contenido dañino, filtración de privacidad, inyección de prompts, exfiltración de datos, uso inseguro de herramientas, denegación de servicio, extracción de modelos, entradas adversarias y fallos con datos incompletos o inusuales.

Los sistemas generativos requieren evaluar los resultados en contexto. Una única puntuación global puede ocultar fallos materiales por idioma, grupo de clientes, flujo de trabajo o tarea. El conjunto de evaluación debe representar la distribución de producción, los casos límite importantes y las rutas de abuso conocidas. La revisión humana debe utilizar criterios definidos, revisores capacitados y conciliación cuando el juicio sea relevante. Las pruebas sintéticas pueden ampliar la cobertura siempre que se identifiquen claramente como sintéticas.

Los criterios de lanzamiento deben aprobarse antes de ver los resultados. El registro debe indicar el rendimiento mínimo, las condiciones de tolerancia cero, el riesgo residual aceptable, los problemas no resueltos, el límite de despliegue y las reglas de parada. Un modelo puede ser técnicamente sólido y aun así quedar fuera del lanzamiento porque los derechos, la seguridad, las adquisiciones, la comunicación con el cliente o el soporte estén incompletos.

El despliegue controlado reduce la exposición mientras genera evidencia. La empresa puede limitar clientes, datos, transacciones, herramientas, autonomía o volumen. La monitorización debe comparar la producción con las hipótesis de evaluación. La deriva material, un incidente o un daño al cliente deben dar lugar a una investigación y a una decisión documentada de continuar, reducir, revertir o retirar.

8. Medir rendimiento, robustez, sesgo y fallos

El rendimiento del modelo debe definirse en relación con una decisión de negocio y las personas afectadas. Un sistema de resumen puede evaluarse por cobertura, afirmaciones no respaldadas y precisión de las citas. Un sistema de previsión puede evaluarse por error, calibración y estabilidad. Un sistema de ranking puede evaluarse por relevancia, exposición y resultados por grupo. Un agente puede evaluarse por éxito de la tarea, selección de herramientas, precisión de las acciones, cumplimiento de políticas y recuperación.

Las pruebas de robustez examinan la variación. Las entradas pueden variar en longitud, idioma, formato, ruido, ambigüedad o intención. Las distribuciones de datos pueden cambiar. Una fuente de recuperación puede quedar desactualizada o no estar disponible. Un proveedor puede actualizar un modelo. La empresa debe probar qué cambios afectan el resultado y establecer monitorización de señales observables.

El análisis de equidad debe ajustarse a la decisión y al contexto legal. El equipo debe identificar grupos relevantes, posibles daños de asignación o de calidad, limitaciones de datos, atributos permitidos y opciones de mitigación. La paridad agregada no establece por sí sola un resultado equitativo. Asesores cualificados deben confirmar los requisitos de empleo, crédito, seguros, consumo y otros requisitos sectoriales cuando proceda.

La gestión de fallos debe diseñarse antes del lanzamiento. El sistema necesita una respuesta segura cuando la confianza es baja, las evidencias entran en conflicto, una herramienta falla o la acción solicitada excede la autoridad. Las opciones incluyen solicitar aclaración, presentar incertidumbre, rechazar la acción, derivar a una persona, usar un mecanismo de respaldo determinista, restringir el alcance o detener el flujo de trabajo.

El plan de monitorización debe asignar un responsable a cada métrica y umbral. Debe incluir rendimiento, latencia, coste, seguridad, privacidad, reclamaciones, intervención manual, incidentes y resultados para el cliente. Las alertas necesitan procedimientos de investigación y autoridad de decisión. Los inversores y compradores empresariales pueden entonces revisar un sistema de control operativo en lugar de una política sin evidencia operativa.

La autoridad aumenta solo cuando las pruebas, los permisos y la responsabilidad humana respaldan la consecuencia.

9. Controlar la AI generativa y la acción agéntica

La AI generativa puede crear resultados fluidos que siguen siendo incompletos, no respaldados o inadecuados para una decisión concreta. El producto debe distinguir el contenido generado de los hechos verificados, exigir fundamentación en fuentes cuando proceda y divulgar al usuario limitaciones significativas. Los resultados de altas consecuencias deben llegar a una persona cualificada antes de la acción.

La AI agéntica añade derechos de acción. Un agente puede invocar herramientas, navegar por sistemas, modificar registros, comunicarse externamente, realizar pedidos o mover fondos. La gobernanza debe definir el objetivo permitido, las herramientas, los datos, las credenciales, los límites de transacción, los límites temporales, los límites de frecuencia, los puntos de control de aprobación, las acciones prohibidas, los registros, la monitorización, la terminación y la recuperación. Los permisos deben seguir el principio de mínimo privilegio y otorgarse durante el periodo práctico más corto.

La escalera de autoridad de la Figura 3 separa informar, recomendar, preparar y actuar. Una empresa puede obtener valor operativo en niveles inferiores mientras acumula evidencia para un nivel superior. El consejo debe resistirse a tratar la autonomía como un objetivo de producto en sí mismo. El caso de negocio debe indicar qué acción mejora el resultado para el cliente y por qué la autoridad añadida merece el riesgo y el coste de control adicionales.

La supervisión humana debe ser significativa. Una persona no puede revisar cientos de acciones complejas en segundos ni aprobar una recomendación sin información relevante. El proceso debe dar al revisor tiempo, competencia, evidencia, autoridad y una forma utilizable de rechazar o modificar la acción. La aprobación automática repetida es una señal de que el control necesita rediseñarse.

La empresa debe probar fallos compuestos. Un agente puede recibir una instrucción maliciosa de contenido recuperado, seleccionar una herramienta con privilegios excesivos, exponer datos confidenciales y luego crear una comunicación externa. Las pruebas de escenarios deben cruzar los límites de los componentes. Los registros deben conservar el objetivo, el plan, las llamadas a herramientas, las entradas, las salidas, las aprobaciones, los errores y la acción final, respetando los requisitos de privacidad y seguridad.

10. Proteger modelos, datos, prompts e interfaces

AI la seguridad debe integrarse en el programa de seguridad más amplio de la empresa y abordar las amenazas específicas del modelo. El equipo de seguridad debe catalogar activos, identidades, flujos de datos, límites de confianza, herramientas y dependencias. Los escenarios de amenaza pueden incluir inyección de prompts, inyección indirecta mediante contenido recuperado, envenenamiento de datos, archivos de modelos maliciosos, deserialización insegura, robo de credenciales, extracción de modelos, divulgación de datos sensibles, denegación de servicio y compromiso de la cadena de suministro.

Los controles pueden incluir aislamiento de entradas y contenido, listas de permitidos de herramientas, mínimo privilegio, restricciones de red, gestión de secretos, separación de entornos, verificación de modelos y paquetes, versiones firmadas, escaneo de dependencias, límites de velocidad, validación de salidas, comprobaciones de permisos de recuperación, monitorización y respuesta a incidentes probada. Las afirmaciones de seguridad deben reflejar evidencia del sistema y la configuración desplegados.

La empresa debe tratar los prompts y las políticas como código cuando afecten materialmente al comportamiento. Necesitan control de versiones, revisión, pruebas y reversión. Los índices de recuperación y las configuraciones de políticas también necesitan registros de cambios. Un modelo base seguro puede volverse inseguro debido a una herramienta con privilegios excesivos, un prompt débil, un secreto expuesto o un límite incorrecto de datos de clientes.

Las pruebas de seguridad deben incluir rutas adversariales realistas. Los ejercicios de red team pueden comprobar si un usuario, documento, página web, integración o cuenta comprometida puede redirigir el modelo o el agente. Los hallazgos deben clasificarse según el riesgo, asignarse y volver a probarse. El registro de la versión debe indicar cualquier limitación aceptada y su control compensatorio.

La respuesta a incidentes debe abarcar la detección, la contención, la preservación de evidencias, la comunicación con clientes y reguladores, la desactivación de modelos o herramientas, la rotación de credenciales, la revisión de datos, la restauración y las lecciones aprendidas. La empresa debe saber cómo detener un modelo, agente o integración sin interrumpir servicios no relacionados. Los clientes empresariales y los inversores pueden solicitar pruebas de que el plan se ha puesto en práctica.

Tabla 3. Evaluación, seguridad y evidencia de la versión

La profundidad requerida debe ajustarse a las consecuencias del sistema, los compromisos con los clientes y las obligaciones aplicables.

11. Establecer supervisión humana y vías de recurso para el cliente

La supervisión humana debe vincularse a las consecuencias. La empresa debe identificar qué decisiones requieren confirmación humana, cuáles pueden revisarse por muestreo, cuáles necesitan revisión especializada y cuáles pueden operar automáticamente dentro de los límites aprobados. El diseño debe indicar qué ve el revisor, qué alternativas están disponibles y cómo se registra el desacuerdo.

Los clientes necesitan información clara sobre el servicio. La comunicación debe explicar el resultado, el papel material de AI cuando sea relevante, los datos importantes, las limitaciones, las responsabilidades del cliente y la vía de acceso al soporte. Una persona afectada por una decisión con consecuencias relevantes puede necesitar una explicación, corrección o apelación conforme a la ley o al contrato aplicables. El producto debe dirigir esa solicitud a alguien que pueda revisar la evidencia subyacente y modificar el resultado cuando esté autorizado.

Los registros de reclamaciones son datos valiosos para la gobernanza. La dirección debe clasificar el sistema, la versión del modelo, el grupo de clientes, el problema, la consecuencia, la resolución y la causa raíz. La confusión repetida puede revelar una divulgación deficiente. Las correcciones repetidas pueden revelar problemas de datos o del modelo. Una resolución lenta puede revelar falta de asignación de responsabilidad. El consejo debe ver patrones materiales junto con el cuadro de mando comercial.

La gobernanza de los empleados también importa. El personal debe saber qué herramientas están aprobadas, qué datos pueden utilizarse, cómo deben comprobarse los resultados y cuándo la comunicación externa requiere revisión. La formación debe reflejar el rol y el riesgo. Los desarrolladores necesitan prácticas de diseño seguras y responsables. Los equipos comerciales necesitan disciplina en las afirmaciones. Los equipos de atención al cliente necesitan escalado y explicación. Los directivos deben conocer las obligaciones en materia de incidentes y de reporte al consejo.

La empresa debe habilitar una vía de denuncia para las preocupaciones relacionadas con AI. Los empleados y contratistas pueden observar uso indebido de datos, afirmaciones no respaldadas, presión para eludir pruebas o daños al cliente. La vía debe proteger la evidencia, asignar la investigación y ofrecer escalado más allá del responsable inmediato del producto.

12. Gobernar las afirmaciones, las ventas, las demostraciones y los materiales para inversores

Las afirmaciones sobre AI deben ser específicas, estar respaldadas y estar actualizadas. Palabras como autónomo, de propiedad exclusiva, preciso, imparcial, seguro, conforme o en tiempo real pueden crear una impresión engañosa cuando omiten dependencias o limitaciones materiales. La empresa debe mantener un registro de afirmaciones que vincule cada declaración con los resultados de las pruebas, el alcance del producto, la versión del modelo, la fecha, el revisor y el canal aprobado.

La aplicación de la ley en Estados Unidos ilustra la exposición. La Securities and Exchange Commission formuló cargos contra dos asesores de inversiones en 2024 por declaraciones falsas y engañosas sobre su supuesto uso de AI. La Federal Trade Commission ha advertido repetidamente a las empresas que respalden las afirmaciones sobre el rendimiento de AI y que cumplan los compromisos de privacidad y confidencialidad. Estos materiales respaldan un principio general de control: las declaraciones sobre productos, marketing y captación de fondos deben coincidir con la capacidad demostrable y el funcionamiento real.

Las demostraciones necesitan la misma disciplina. Un ejemplo curado, un resultado asistido por humanos o un prototipo deben describirse con precisión. La empresa debe distinguir las funcionalidades en producción de los elementos de la hoja de ruta. Si la demostración utiliza datos sintéticos, una integración por etapas o una revisión manual, el público debe recibir ese contexto. Los equipos de ventas no deben prometer un estatus regulatorio, una propiedad de seguridad o un nivel de rendimiento que no hayan sido aprobados.

Los materiales para inversores deben conciliar las afirmaciones sobre el producto y las financieras. Si el modelo es de terceros, la presentación no debe implicar la propiedad del modelo fundacional. Si el margen supone un menor coste futuro de inferencia, la previsión debe identificar esa hipótesis. Si los ingresos dependen de la aprobación de seguridad empresarial o de un permiso regulatorio, el plan debe indicar la condición previa. Si los resultados de los clientes se basan en un piloto, la cohorte y el método deben ser claros.

El consejo de administración debería aprobar las declaraciones sustantivas sobre AI utilizadas en la captación de fondos. Una sala de datos debería contener el registro de manifestaciones, el mapa de modelos y proveedores, las evaluaciones, la evidencia de seguridad, las limitaciones de los clientes, el análisis de derechos, los incidentes y las cuestiones abiertas. La divulgación precisa respalda la diligencia debida y reduce el riesgo de que el entusiasmo comercial se convierta en una declaración inexacta.

Los valores son supuestos ilustrativos de la dirección y deben sustituirse por cohortes y contratos verificados.

13. Mapear la regulación y las obligaciones de entrada en el mercado

La regulación de AI varía según la jurisdicción, el sector, la actividad y la función. Una startup debería mapear dónde desarrolla, suministra y despliega el sistema; dónde se encuentran los usuarios y las personas afectadas; qué datos se tratan; y qué productos o decisiones regulados están implicados. El mapa debería distinguir la ley vinculante, las normas de los reguladores, los requisitos contractuales, las normas voluntarias y las propuestas.

El Reglamento de AI de la Unión Europea se aplica de forma progresiva. El calendario oficial del servicio de asistencia indica que las definiciones, los requisitos de alfabetización en AI y las prohibiciones se aplicaron desde febrero de 2025; las obligaciones y la gobernanza de la AI de uso general, desde agosto de 2025; y la mayoría de las normas restantes y las obligaciones de transparencia del artículo 50, desde agosto de 2026, sujeto al calendario publicado y a las enmiendas del Ómnibus Digital. Las normas sobre sistemas de alto riesgo tienen fechas posteriores. Una empresa debería confirmar su función, categoría de sistema, transición y situación de mercado con asesoramiento jurídico cualificado.

La Carta UAE para el Desarrollo y el Uso de la Inteligencia Artificial establece principios nacionales para la AI responsable. La Ley UAE de Protección de Datos Personales rige el tratamiento de datos personales. Las normas sectoriales pueden añadir requisitos, especialmente en servicios financieros, salud y actividad gubernamental. Los Principios de Ética de AI de la SDAIA saudí utilizan categorías de riesgo y controles del ciclo de vida para las partes interesadas que desarrollan, despliegan o utilizan sistemas de AI en el Reino.

El Reino Unido aplica la legislación existente en materia de privacidad, consumo, igualdad, productos, servicios financieros y otras áreas, junto con su enfoque de AI entre reguladores. El conjunto de herramientas del ICO respalda el análisis de riesgos de protección de datos de AI. La FCA señala que los marcos existentes, incluidos el deber de consumo (Consumer Duty), la responsabilidad de la alta dirección, la gobernanza y los controles, se aplican a la AI en los servicios financieros. Los marcos de la IMDA de Singapur proporcionan una gobernanza práctica para la AI tradicional, generativa y agéntica. Los principios de la OCDE respaldan la interoperabilidad en torno a los derechos humanos, la transparencia, la robustez, la seguridad y la rendición de cuentas.

La entrada en el mercado debería contar con un control legal y operativo. El consejo de administración debería exigir un mapa escrito de roles y obligaciones, fechas de vigencia actuales, controles de producto, divulgaciones a clientes, interacción con el regulador o el régimen cuando sea necesario y un responsable del seguimiento de cambios. Un marco o una norma voluntaria puede respaldar la gobernanza sin establecer por sí mismo el cumplimiento legal.

Tabla 4. Mapa de gobernanza y entrada en el mercado de AI en varios mercados

Esta tabla resume las posiciones oficiales de los marcos en el momento de la publicación; cada empresa debe volver a verificar la legislación vigente, su rol y las fechas de entrada en vigor antes del lanzamiento.

14. Convertir la gobernanza en preparación para las compras empresariales

Los clientes empresariales a menudo evalúan a un proveedor de AI mediante revisiones de seguridad, privacidad, resiliencia, jurídicas, de compras y de los responsables de negocio. Un fundador puede acortar ese proceso manteniendo una sala de evidencias actualizada. La sala debe ajustarse al alcance real del producto y evitar certificaciones o políticas genéricas que no cubran el servicio desplegado.

El paquete de evidencias puede incluir la descripción del sistema, la arquitectura, el flujo de datos, el programa de seguridad, la prueba de penetración, el proceso de vulnerabilidades, el plan de incidentes, la evaluación de privacidad, la lista de encargados del tratamiento, las ubicaciones de los datos, el registro de modelos y proveedores, las evaluaciones, el plan de continuidad del negocio, los niveles de servicio, el seguro, las condiciones para clientes, la posición en materia de propiedad intelectual y el soporte para la salida. Cuando exista una certificación, la dirección debería identificar su alcance, fecha y exclusiones.

Los cuestionarios de clientes deberían alimentar el sistema de gobernanza. Las preguntas repetidas revelan qué evidencias exigen los compradores. Las excepciones repetidas revelan brechas de producto o de contrato. La empresa puede crear respuestas estándar respaldadas por documentos controlados y responsables designados. Los compromisos materiales específicos de cada cliente deberían incorporarse al backlog de producto y de monitorización.

Debe medirse la economía de las compras. La revisión de seguridad, la negociación jurídica, la integración, la evaluación de modelos, el alojamiento específico para clientes y el soporte consumen efectivo. Las previsiones de ingresos deben incluir la probabilidad de aprobación, el tiempo de implementación, la renovación, la expansión y el coste del servicio. Un contrato grande con responsabilidad amplia, controles personalizados y un margen bruto bajo puede debilitar el caso de financiación.

El consejo debería revisar la relación entre la madurez de la gobernanza y la ejecución de ventas utilizando datos observados de la empresa. Las medidas útiles incluyen el tiempo de respuesta a cuestionarios, el tiempo hasta la aprobación de seguridad, las excepciones materiales, el ciclo contractual, el tiempo de implementación, los incidentes con clientes, la renovación y la contribución. La empresa debería evitar afirmar una mejora causal de la valoración sin evidencia de transacciones.

15. Vincular la gobernanza con la economía unitaria y la valoración

La economía unitaria de AI debería incluir el coste de entregar un resultado controlado. Las tarifas de computación y de modelos son un componente. La adquisición y recuperación de datos, la observabilidad, la seguridad, la revisión humana, el soporte, la remediación de incidentes, los controles específicos para clientes, el cumplimiento, el seguro y los mínimos de proveedores pueden cambiar materialmente la contribución.

El equipo de finanzas debería trazar una cohorte desde el usuario elegible hasta el resultado de éxito y retención. Debería registrar las llamadas a modelos, los tokens o el cómputo, los reintentos, el uso de herramientas, las intervenciones humanas, el soporte, los reembolsos y las pérdidas. La segmentación por flujo de trabajo, cliente y modelo puede revelar dónde un alto margen aparente oculta fallos o revisiones costosos.

La mejora del modelo puede afectar la economía a través de una mayor finalización de tareas, menos reintentos, una reducción de la revisión humana, un menor tiempo de tramitación o una mayor retención. Un modelo más grande puede mejorar la calidad al tiempo que aumenta el coste y la latencia. Un modelo más pequeño o especializado puede mejorar la contribución para una tarea acotada. El enrutamiento debe contar con gobernanza y evaluarse como parte del producto.

La valoración debe basarse en evidencia duradera de flujo de caja, derechos estratégicos y crecimiento ajustado al riesgo. La gobernanza puede respaldar el caso protegiendo los derechos sobre los datos, fortaleciendo los procesos de compra empresarial, reduciendo sorpresas de dependencia, respaldando las afirmaciones y haciendo medible el desempeño operativo. El efecto real en la valoración depende de los resultados de la empresa, las condiciones de mercado, el juicio del inversor y los términos de la transacción. No debe presentarse como una prima fija.

El consejo debe utilizar escenarios. Un caso base puede reflejar los precios actuales del modelo, la conversión observada y la revisión aprobada. Un caso al alza puede reflejar automatización evidenciada y distribución firmada. Un caso a la baja puede reflejar aumentos de precios de proveedores, compras más lentas, un incidente del modelo, revisión humana adicional o regulación retrasada. Cada escenario debe mostrar el runway de caja y la decisión disponible para la dirección.

Los tramos de financiación y los valores de participación son supuestos ilustrativos de la dirección; las decisiones de la empresa requieren una tabla de capitalización verificada y términos de financiación aprobados.

16. Financiación por etapas, tabla de capitalización y uso de los fondos

El plan de financiación debe conectar el capital con evidencia específica. Los fondos iniciales pueden establecer la definición del sistema, los derechos sobre los datos, una arquitectura segura y una evaluación representativa. El siguiente tramo puede respaldar clientes controlados, procesos de compra empresarial y métricas operativas. El capital de la Serie A puede entonces financiar la distribución, la expansión del producto y la capacidad organizativa frente a un caso de riesgo y economía mejor definido.

El uso de los fondos debe separar el desarrollo de producto, el coste de modelos y datos, la seguridad, la privacidad y el trabajo legal, las integraciones empresariales, las ventas, el soporte al cliente, la capacidad de respuesta ante incidentes y el capital circulante. Un presupuesto etiquetado como ingeniería puede ocultar la inversión en gobernanza necesaria. Los inversores deben poder ver qué gasto genera un hito de liberación y qué gasto respalda el crecimiento después de dicho hito.

La tabla de capitalización debe incluir acciones emitidas, opciones, warrants, convertibles, SAFEs u otros instrumentos, preferencias de liquidación, derechos pro rata, derechos de información, derechos de consentimiento y cualquier participación en fondos propios de socios de modelo o datos. La dirección debe modelar la titularidad y los importes obtenidos bajo términos de financiación plausibles. Los porcentajes ilustrativos de la Figura 5 demuestran un método y no recomiendan una transacción.

El consejo debe proteger la flexibilidad operativa. Los documentos de financiación, las alianzas estratégicas y los acuerdos con clientes pueden afectar la elección de modelo, el uso de datos, la exclusividad, los precios, la captación de fondos, la propiedad intelectual y el cambio de control. Estas restricciones deben revisarse en conjunto. Un acuerdo de distribución atractivo puede debilitar la opcionalidad si concede una exclusividad amplia o la titularidad de las mejoras.

La planificación del runway debe incluir la volatilidad de costes de AI y los plazos de compra. El caso a la baja puede modelar un mayor coste de inferencia, una aprobación empresarial más lenta, revisión humana adicional o una suspensión temporal del lanzamiento. El consejo debe aprobar desencadenantes para la contratación, los compromisos y otro proceso de financiación. Las previsiones siguen siendo estimaciones de la dirección hasta que se respalden con cobros reales, contratos y datos operativos.

Tabla 5. Lista de verificación de evidencia del data room de la Serie A y para inversores

Los requisitos de los inversores varían; esta lista de verificación organiza la evidencia de producto, comercial, legal y operativa que suele ser relevante.

17. Ejecutar un programa pre-Serie A de 120 días

Los días uno a veinte establecen visibilidad. La dirección define el resultado del producto, inventaría los sistemas y las dependencias, mapea los datos y los derechos de propiedad intelectual, identifica las jurisdicciones y asigna niveles de riesgo. El consejo aprueba el apetito de riesgo de AI, la rendición de cuentas y los casos de uso relevantes. La primera puerta de decisión exige un inventario actual y una vía aceptable para los derechos críticos.

Del día veintiuno al cuarenta y cinco se establecen los controles del ciclo de vida. Los equipos de producto, ingeniería, seguridad, privacidad y comercial definen los criterios de evaluación, los escenarios de amenaza, los requisitos de proveedores, la aprobación de declaraciones, la respuesta a incidentes y las vías de recurso del cliente. La empresa prueba la configuración de producción y cierra los hallazgos críticos. La segunda puerta exige evidencia reproducible y un alcance de lanzamiento acotado.

Del día cuarenta y seis al setenta se consolidan la prueba de cliente y de compras. La empresa ejecuta una cohorte controlada, completa la evidencia empresarial, concilia las declaraciones con los resultados y mide el coste del servicio. Registra reclamaciones, anulaciones, eventos de seguridad y cambios de modelo. La tercera puerta exige un resultado demostrable para el cliente, un rendimiento controlado y una ruta de compras ejecutable.

Del día setenta y uno al noventa y cinco se establecen la economía y la preparación del mercado. Finanzas construye el puente de economía unitaria, las cohortes de clientes, la sensibilidad al coste del modelo, la hoja de ruta de financiación y los escenarios de tabla de capitalización. Los asesores legales y regulatorios confirman el análisis aplicable de entrada al mercado. La cuarta puerta exige una contribución basada en evidencia y las condiciones jurisdiccionales vigentes.

Del día noventa y seis al ciento veinte se prepara la transacción. La dirección construye el data room, concilia los estados financieros y de producto, prepara los materiales para el consejo y cierra las excepciones prioritarias. La quinta puerta autoriza un alcance de captación de fondos definido, el uso de los fondos, la posición de divulgación y el plan operativo. Las brechas materiales permanecen identificadas con responsables y consecuencias.

Cada fase termina con evidencia que el consejo puede aprobar, condicionar o devolver para su subsanación.

18. Hacer explícita la decisión del consejo y del inversor

El paquete final para el consejo debe presentar el resultado del producto, el inventario de sistemas, los niveles de riesgo, los derechos sobre datos y modelos, la arquitectura, las dependencias de proveedores, las evaluaciones, la evidencia de seguridad, la supervisión humana, las vías de recurso del cliente, el registro de declaraciones, el mapa regulatorio, la preparación de compras, la economía unitaria, el plan de financiación, la tabla de capitalización y el estado del data room. Cada elemento debe identificar su fuente, responsable, fecha y asunto pendiente.

El consejo debe aprobar una decisión acotada. Puede autorizar una versión definida del sistema, su uso, una cohorte de clientes, una jurisdicción, un nivel de autonomía, una ruta de distribución y un presupuesto de capital. Las condiciones pueden incluir hallazgos de seguridad cerrados, derechos de datos vigentes, declaraciones aprobadas, monitorización probada, capacidad de atención al cliente y una fecha de revisión fija. La expansión debe exigir la siguiente puerta de evidencia.

La dirección debe expresar la incertidumbre con claridad. Un análisis legal pendiente, un compromiso de proveedor, una aprobación de cliente, una mejora del modelo, un resultado de captación de fondos o una conversión de previsiones deben conservar su estado actual. La empresa debe distinguir entre ingresos firmados, desplegados, facturados, cobrados y previstos. Debe distinguir la capacidad probada de la hoja de ruta y el acceso al mercado aprobado de una solicitud o un plan.

La decisión del inversor debe reflejar tanto el crecimiento como la controlabilidad. La cuestión de diligencia debida es si la empresa puede convertir capital en valor para el cliente mediante sistemas y derechos que sigan disponibles, medibles y gobernables. Un programa sólido de gobernanza proporciona al consejo y al inversor una base común de evidencia para ese juicio.

La decisión operativa continúa después de la financiación. Los nuevos mercados, modelos, datos, agentes, adquisiciones y compromisos con clientes deben volver a entrar en el mismo sistema de inventario, clasificación por niveles, evidencia, aprobación y monitorización. La gobernanza sigue formando parte de la ejecución de producto y de capital a medida que la empresa crece.

Tabla 6. Lista de verificación de gobernanza y decisión de Serie A del consejo AI

Cada punto de control requiere evidencia actual, un responsable designado y una decisión registrada del consejo o una decisión delegada.

Conclusión de implementación

La gobernanza de AI antes de la Serie A comienza con visibilidad. La empresa define cada sistema, consecuencia, derecho y dependencia, y luego asigna responsables y puntos de control de evidencia basados en riesgos. Conecta el rendimiento del modelo con los derechos sobre los datos, la seguridad, las vías de recurso para el cliente, las reclamaciones y los aspectos económicos.

El programa de 120 días produce cinco decisiones del consejo: aprobar el sistema y el mapa de derechos; aprobar el desarrollo y el lanzamiento controlados; verificar la evidencia de clientes y compras; validar los aspectos económicos y la entrada en el mercado; y autorizar un proceso de financiación conciliado. El resultado es un registro operativo práctico que inversores, clientes empresariales y reguladores pueden examinar.

Los requisitos de los inversores siguen siendo específicos del fondo, la etapa, el producto, el mercado y la transacción. Los efectos de valoración, financiación, coste y calendario mostrados en las cifras son supuestos ilustrativos de la dirección. Las decisiones de la empresa deben basarse en contratos verificados, cohortes, evidencia técnica y asesoramiento profesional cualificado.

Referencias

1. Instituto Nacional de Estándares y Tecnología. Marco de Gestión de Riesgos de AI. https://www.nist.gov/itl/ai-risk-management-framework
2. Instituto Nacional de Estándares y Tecnología. Marco de Gestión de Riesgos de Inteligencia Artificial: Perfil de Inteligencia Artificial Generativa, NIST AI 600-1. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
3. Organización Internacional de Normalización. ISO/IEC 42001:2023, sistema de gestión de inteligencia artificial. https://www.iso.org/standard/42001
4. Servicio de asistencia del Reglamento AI de la Comisión Europea. Cronograma para la implementación del Reglamento AI de la UE. https://ai-act-service-desk.ec.europa.eu/en/ai-act/eu-ai-act-implementation-timeline
5. Oficina de Inteligencia Artificial de UAE. Carta de UAE para el Desarrollo y Uso de la Inteligencia Artificial, julio de 2024. https://ai.gov.ae/wp-content/uploads/2024/07/UAEAI-Methaq-EN2-3.pdf
6. Legislación de los Emiratos Árabes Unidos. Decreto-ley federal n.º 45 de 2021 sobre la protección de datos personales. https://uaelegislation.gov.ae/en/legislations/1972
7. Autoridad de Datos e Inteligencia Artificial de Arabia Saudí. Principios éticos de AI. https://sdaia.gov.sa/en/SDAIA/about/Documents/ai-principles.pdf
8. Autoridad de Desarrollo de Medios e Infocomunicaciones de Singapur. Inteligencia artificial en Singapur y marcos modelo de gobernanza de AI. https://www.imda.gov.sg/AI
9. Oficina del Comisionado de Información. AI y conjunto de herramientas de riesgo de protección de datos. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/ai-and-data-protection-risk-toolkit/
10. Autoridad de Conducta Financiera. AI y la FCA: nuestro enfoque. https://www.fca.org.uk/firms/innovation/ai-approach
11. Autoridad de Conducta Financiera. AI en los servicios financieros: configurar nuestro enfoque mediante la colaboración con el sector, 8 de junio de 2026. https://www.fca.org.uk/news/blogs/ai-financial-services-approach
12. Organización para la Cooperación y el Desarrollo Económicos. Principios de AI. https://www.oecd.org/en/topics/ai-principles.html
13. Comisión de Bolsa y Valores de EE. UU. La SEC acusa a dos asesores de inversión de realizar declaraciones falsas y engañosas sobre su uso de la inteligencia artificial, 18 de marzo de 2024. https://www.sec.gov/newsroom/press-releases/2024-36
14. Comisión Federal de Comercio de EE. UU. Empresas de AI: cumplan sus compromisos de privacidad y confidencialidad, 9 de enero de 2024. https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2024/01/ai-companies-uphold-your-privacy-confidentiality-commitments