Gobernanza de IA para empresas B2B medianas: los controles mínimos antes de producción
La mayoría de las empresas en crecimiento comete uno de dos errores de gobernanza de IA.
El primero es no crear prácticamente ninguna gobernanza.
Los empleados abren cuentas de IA individuales, suben documentos, conectan extensiones del navegador, generan comunicaciones para clientes y automatizan tareas sin un inventario compartido ni un proceso de revisión.
El segundo es copiar un marco de gobernanza corporativo diseñado para una organización global regulada.
Se crea un comité. Cada experimento requiere varias aprobaciones. La documentación crece más rápido que la implementación. Con el tiempo, los equipos esquivan el proceso porque no puede sostener la velocidad operativa normal.
Ninguno de los dos enfoques funciona.
Una empresa B2B de 50-250 empleados no necesita un consejo de IA de treinta personas.
Lo que sí necesita saber es: qué sistemas de IA se están usando; quién es responsable de cada sistema; qué datos entran en él; qué decisiones o acciones afecta; cómo se probó; qué fallas requieren escalamiento; y qué ocurre cuando cambia el modelo, el proveedor o el flujo de trabajo.
La gobernanza de IA no es un documento que diga que los empleados deben usar la IA de forma responsable. Es el sistema operativo mediante el cual la empresa aprueba, controla, mide, modifica y retira los casos de uso de IA.
Un modelo mínimo y práctico de gobernanza contiene diez controles: un inventario de sistemas y casos de uso de IA; un responsable de negocio por sistema; una clasificación de riesgos basada en el impacto y la autonomía; reglas de uso de datos y proveedores; una evaluación definida antes de producción; permisos y límites de aprobación humana; monitoreo de calidad, costo e incidentes; un proceso de escalamiento y apagado; control de cambios para modelos, prompts, herramientas y datos; y revisión periódica y retiro de los sistemas obsoletos.
NIST estructura la gestión de riesgos de IA en torno a cuatro funciones: Govern, Map, Measure y Manage (gobernar, mapear, medir y gestionar). Su marco es voluntario y está diseñado para adaptarse a organizaciones de distintos tamaños y sectores. El Generative AI Profile amplía ese enfoque y presta atención a la gobernanza, las pruebas previas al despliegue, la procedencia y la divulgación de incidentes. (Publicaciones de NIST)
Para una empresa mediana, estos principios deben traducirse en controles operativos ligeros, en lugar de copiarse como un gran programa de cumplimiento.
Empiece con un inventario
Una empresa no puede gobernar sistemas que no sabe que existen.
El inventario debe incluir más que las plataformas compradas de forma centralizada. Debe abarcar la IA integrada en el SaaS existente; los asistentes creados por empleados; las automatizaciones basadas en API; el chat o la búsqueda de cara al cliente; los informes generados por IA; los agentes conectados a herramientas de negocio; los flujos de procesamiento de documentos; los sistemas de puntuación y recomendación; y los pilotos experimentales que usan información de la empresa.
Qué debe contener el inventario
| Campo | Qué registrar |
|---|---|
| Sistema o caso de uso | Qué hace la IA |
| Responsable de negocio | Quién responde por el resultado |
| Responsable técnico | Quién lo opera o le da soporte |
| Usuarios | Empleados, clientes, proveedores o el público |
| Proveedor y modelo | Qué componentes externos o internos se usan |
| Datos | Qué información se envía, recupera, almacena o genera |
| Resultado | Borrador, recomendación, decisión o acción autónoma |
| Integraciones | Sistemas que la IA puede leer o modificar |
| Nivel de riesgo | Impacto operativo si se equivoca o no está disponible |
| Estado de aprobación | Piloto, producción restringida, producción, suspendido |
| Última revisión | Cuándo se reevaluó el sistema por última vez |
| Alternativa de respaldo | Cómo funciona el proceso sin la IA |
Al principio puede bastar con una hoja de cálculo.
El valor proviene de la asignación de responsables y de la revisión, no de comprar una plataforma de gobernanza.
Clasifique el caso de uso, no solo el modelo
El mismo modelo puede generar niveles de riesgo muy distintos.
Usar un LLM para reescribir una nota interna de una reunión no equivale a usarlo para aprobar un reembolso; clasificar a candidatos a un empleo; cambiar los derechos de un cliente; enviar texto contractual; modificar registros financieros; o dar asesoría específica a un cliente.
El riesgo depende del caso de uso completo:
Modelo + datos + usuario + decisión + integración + autonomía + consecuencia
Un modelo de riesgo proporcional
| Nivel | Uso típico | Control mínimo |
|---|---|---|
| Nivel 1: Asistencia | Borradores internos, lluvia de ideas, resúmenes de información no sensible | Herramientas aprobadas, reglas básicas de datos, responsabilidad del empleado |
| Nivel 2: Apoyo operativo | Clasificación, búsqueda, enrutamiento, borradores de respuestas a clientes | Responsable designado, conjunto de evaluación, registro de actividad, revisión humana |
| Nivel 3: Recomendación relevante | Recomendaciones de precios, calificación, análisis financiero o contractual | Aprobación formal, evidencia documentada, acceso restringido, pruebas periódicas |
| Nivel 4: Acción autónoma de alto impacto | Pagos, cambios de acceso, comunicaciones vinculantes, acciones laborales o críticas para la seguridad | Aceptación del riesgo por la dirección, controles técnicos sólidos, aprobación humana explícita o prohibición |
La clasificación debe considerar el impacto de un resultado incorrecto; la reversibilidad; la cantidad de personas o registros afectados; la sensibilidad de los datos; el grado de autonomía; la visibilidad de la falla; la dependencia de terceros; y la posibilidad de volver a un proceso manual.
Un modelo de alto rendimiento no convierte un caso de uso de alto impacto en uno de bajo riesgo.
Asigne un responsable de negocio
El equipo de IA puede construir la solución.
TI puede operar la infraestructura.
Seguridad puede evaluar los controles técnicos.
Un proveedor puede suministrar el modelo.
Ninguno de ellos es responsable automáticamente del resultado de negocio.
Para cada sistema, una persona debe responder por el uso previsto; los criterios de éxito; el error aceptable; el manejo de excepciones; las reglas de aprobación; la capacitación de los usuarios; la respuesta a incidentes; el valor de negocio continuo; y la decisión de modificar o detener el sistema.
En la práctica
Para un sistema de IA que califica leads: Operaciones de Ventas puede ser responsable del resultado de negocio; TI puede encargarse del acceso a la plataforma; Seguridad puede revisar los permisos; Datos o RevOps puede encargarse del conjunto de datos de evaluación; y El proveedor puede operar el modelo subyacente.
Pero un responsable de negocio con nombre propio debe decidir qué significa "calificado" y asumir la responsabilidad por el proceso resultante.
"La IA es dueña de la decisión" nunca es un modelo de rendición de cuentas.
Establezca reglas para el manejo de datos
Los empleados suelen interpretar que una herramienta de IA aprobada es una autorización para ingresar en ella cualquier información de la empresa.
Son decisiones separadas.
La política debe distinguir entre información pública; información interna común; información confidencial del negocio; información personal; información controlada por el cliente; credenciales y secretos; e información restringida por ley o protegida por contrato.
Para cada categoría, indique si puede ingresarse manualmente; subirse; recuperarse mediante una integración; conservarse en los registros; usarse para mejorar los servicios del proveedor; procesarse solo bajo un acuerdo separado; o si está prohibida por completo.
La política también debe reflejar lo que el sistema hace en realidad.
Un chatbot usado desde el navegador y una integración por API conectada a un CRM pueden tener flujos de datos distintos aunque usen el mismo proveedor.
La revisión de proveedores es más que leer la página de seguridad
El material de marketing de un proveedor no reemplaza la debida diligencia.
La revisión debe abordar:
| Área | Pregunta |
|---|---|
| Flujo de datos | ¿Qué datos salen de la empresa y a dónde van? |
| Retención | ¿Cuánto tiempo se conservan las entradas, los resultados, los archivos y los registros? |
| Entrenamiento y mejora | ¿Bajo qué condiciones del producto pueden usarse los datos? |
| Subencargados | ¿Qué otras partes participan? |
| Acceso | ¿Puede el personal del proveedor acceder a los datos del cliente? |
| Seguridad | ¿Qué controles y evaluaciones independientes existen? |
| Cambios de modelo | ¿Puede cambiar el comportamiento sin la aprobación del cliente? |
| Disponibilidad | ¿Qué ocurre cuando el servicio falla o limita la tasa de solicitudes? |
| Portabilidad | ¿Se pueden exportar los prompts, los resultados, las configuraciones y los datos fuente? |
| Terminación | ¿Qué ocurre con los datos y los flujos de trabajo cuando termina el contrato? |
No toda herramienta de bajo riesgo requiere un proceso de compra de varios meses.
Pero los sistemas de alto impacto no deben pasar a producción porque un proveedor hizo una demostración convincente.
Defina el éxito antes del piloto
Un piloto sin criterios de aceptación suele producir un resultado ambiguo.
Los participantes dicen: los resultados parecían útiles; el modelo parecía inteligente; varias tareas fueron más rápidas; y algunas respuestas necesitaron corrección.
Ninguna de estas afirmaciones respalda una decisión de pasar a producción. Nuestra guía para evaluar agentes de IA antes de pasar a producción ofrece métricas concretas y un diseño de conjuntos de pruebas para convertir las impresiones del piloto en evidencia medible.
Defina la tarea de negocio; la línea base; el conjunto de datos de evaluación; la calidad requerida; las fallas prohibidas; el esfuerzo de revisión humana; la latencia; el costo operativo; los criterios de escalamiento; la duración del piloto; y la regla de decisión para pasar a producción.
Qué medir
| Métrica | Qué muestra |
|---|---|
| Tasa de éxito de las tareas | Porcentaje de tareas de negocio completadas correctamente |
| Tasa de corrección humana | Con qué frecuencia los empleados deben reparar el resultado |
| Tasa de escalamiento | Con qué frecuencia el sistema no puede completar la tarea de forma segura |
| Tasa de afirmaciones sin sustento | Frecuencia de afirmaciones no basadas en evidencia aprobada |
| Tasa de acciones prohibidas | Si el sistema traspasa los límites de la política |
| Costo por tarea completada | Costo total de IA y revisión por cada resultado útil |
| Reducción del tiempo de ciclo | Si el proceso de negocio realmente se volvió más rápido |
| Visibilidad de las fallas | Si los resultados incorrectos se detectan antes de que tengan impacto |
Un sistema que ahorra diez minutos pero genera doce minutos de revisión no ha automatizado la tarea.
Ha trasladado el trabajo.
La supervisión humana debe ser operativa
"Human-in-the-loop" (con una persona en el circuito) aparece a menudo en los documentos de gobernanza sin especificar cómo participa esa persona.
Un modelo de revisión que funciona responde: quién revisa; qué acciones revisa; qué evidencia ve; qué constituye una aprobación; si los parámetros pueden cambiar después de la aprobación; qué ocurre cuando el revisor no responde; cómo se escalan los casos urgentes; y cómo se mide la calidad de la revisión.
La guía de seguridad para agentes de OWASP recomienda una aprobación explícita para las acciones de alto impacto o irreversibles, vistas previas de las acciones, límites de autonomía basados en el riesgo, registros de auditoría, y capacidades de interrupción y reversión. (OWASP Cheat Sheet Series)
Nuestro análisis de por qué los agentes de IA no son automatización describe en detalle cómo deben ser los límites de decisión y las interfaces de aprobación cuando un agente puede elegir sus propias acciones.
Supervisión que solo existe en el papel
Un gerente revisa las decisiones de la IA cuando es necesario.
Supervisión que funciona en la práctica
Las recomendaciones de reembolso superiores a $250 requieren la aprobación del responsable de la cuenta. La vista de aprobación debe mostrar el cliente, el monto, la transacción de origen, la regla de la política, la evidencia de respaldo y los parámetros exactos de ejecución. La aprobación vence a las dos horas y no puede reutilizarse si cambia el monto o el destinatario.
El segundo modelo se puede implementar y auditar.
El primero no.
Separe la recomendación de la ejecución
En las operaciones relevantes, la IA no debe ser el único componente que decide y ejecuta la acción.
Un patrón más seguro es:
- Análisis de IA
- Acción propuesta estructurada
- Validación de políticas y esquema
- Aprobación humana o determinista
- Servicio de ejecución restringido
- Evento de auditoría
Esto crea puntos de control independientes.
También impide que un prompt, un documento recuperado o un error del modelo se conviertan directamente en una acción en producción.
El prompt del sistema debe orientar el comportamiento.
No debe servir como único mecanismo de autorización.
Registre lo suficiente para investigar, pero no todo
La gobernanza requiere trazabilidad, pero un registro indiscriminado crea otro riesgo.
Los registros útiles pueden incluir el caso de uso y el ID de la tarea; la identidad del usuario y del agente; la versión del modelo y de la configuración; las fuentes de datos aprobadas; las referencias recuperadas; la operación seleccionada; los parámetros estructurados; la aprobación; el estado del resultado; la latencia; el costo; el error; y el escalamiento o la anulación manual.
No almacene automáticamente: credenciales; documentos confidenciales completos; datos sensibles de clientes; historiales de prompts sin restricciones; ni información personal innecesaria.
Los registros deben permitir reconstruir un incidente sin convertirse en un duplicado sin control de los datos sensibles de la empresa.
Prepárese para los incidentes antes de producción
Un incidente de IA no se limita a una brecha de seguridad.
Puede incluir comunicaciones incorrectas y repetidas a clientes; exposición indebida de datos; acciones autónomas inesperadas; errores relevantes en los informes; sesgo sistemático en el enrutamiento o la puntuación; costos sin control; degradación del modelo; indisponibilidad del servicio del proveedor; y memoria o fuentes de recuperación corruptas.
El plan de respuesta debe definir quién recibe la alerta; quién puede suspender el sistema; cómo se revocan las credenciales y las integraciones; cómo se identifican los registros afectados; si las acciones pueden revertirse; quién se comunica con los clientes o socios; qué evidencia debe conservarse; y qué condiciones permiten que el sistema vuelva a operar.
El Generative AI Profile de NIST trata la divulgación de incidentes y la gestión de riesgos a lo largo del ciclo de vida como partes importantes de un despliegue responsable, y no como trabajo administrativo posterior al proyecto. (Publicaciones de NIST)
Gobierne los cambios, no solo el lanzamiento inicial
Un sistema de IA puede cambiar sin que el flujo de trabajo del negocio parezca cambiar.
El rendimiento puede verse afectado por: una versión distinta del modelo; un prompt del sistema modificado; una herramienta nueva; permisos modificados; una base de conocimiento revisada; un nuevo modelo de embeddings o de reordenamiento; cambios en las definiciones del negocio; actualizaciones del lado del proveedor; nuevos grupos de usuarios; y una mayor autonomía.
Todo cambio relevante debe responder: ¿Cambia el nivel de riesgo? ¿Debe volver a ejecutarse el conjunto de evaluación? ¿Siguen siendo válidas las aprobaciones anteriores? ¿Cambió el flujo de datos? ¿Cambió el modelo de costos? ¿Se puede restaurar la versión anterior?
Una aprobación para producción se aplica a una configuración probada, no a cualquier sistema futuro que lleve el mismo nombre.
Un modelo de gobernanza viable
Una organización mediana no necesita un gran comité permanente.
Necesita roles claros.
| Cargo | Responsabilidad |
|---|---|
| Patrocinador ejecutivo | Fija la tolerancia al riesgo y resuelve las decisiones de alto impacto |
| Responsable de negocio | Es responsable del proceso, el resultado y el valor continuo |
| Responsable técnico | Opera el sistema, las integraciones, las versiones y la alternativa de respaldo |
| Revisor de seguridad y privacidad | Revisa el acceso, el flujo de datos, los proveedores y los controles de incidentes |
| Evaluador o responsable de datos | Mantiene los casos de prueba, la evidencia y los umbrales de rendimiento |
| Revisor humano | Aprueba o corrige clases definidas de resultados |
| Usuarios | Siguen las reglas de uso aprobado y reportan las fallas |
En una organización más pequeña, una misma persona puede cumplir varios roles.
Aun así, las responsabilidades deben ser explícitas.
Cómo debe funcionar la aprobación
- Solicitud del caso de uso
- Responsable de negocio y valor esperado
- Clasificación de riesgos
- Revisión de datos y proveedores
- Piloto limitado
- Evaluación frente a los criterios de aceptación
- Aprobación para producción restringida
- Monitoreo y revisión periódica
- Ampliación, corrección, suspensión o retiro
Los usos internos de bajo riesgo pueden pasar rápidamente por este proceso.
Los sistemas autónomos de alto impacto requieren más evidencia y controles más sólidos.
La gobernanza debe ser proporcional, no opcional.
Atajos que crean riesgos ocultos
"Todos ya usan IA, así que prohibirla no es realista"
Diagnóstico correcto, conclusión equivocada.
Una prohibición total suele llevar el uso a la clandestinidad. La mejor respuesta es ofrecer herramientas aprobadas, reglas de datos claras y una vía para evaluar nuevos casos de uso.
"El proveedor se encarga de la gobernanza"
El proveedor puede gobernar su plataforma.
No es dueño de: su proceso; su clasificación de datos; el comportamiento de sus empleados; sus integraciones; sus compromisos con clientes; su política de aprobación; ni las consecuencias para su negocio.
"Agregaremos la gobernanza después del piloto"
Con frecuencia, los pilotos obtienen acceso a datos y sistemas de producción antes de que se les llame formalmente producción.
Como mínimo, la asignación de responsables, las restricciones de datos, la evaluación, las credenciales y el mecanismo de apagado deben existir antes de que comience el piloto. Los requisitos de higiene de credenciales y accesos coinciden directamente con los controles estándar de riesgo de TI (sobre todo en lo relativo a la proliferación de cuentas, MFA y shadow IT).
"El empleado revisa cada resultado"
La revisión no crea control cuando: el empleado no ve la evidencia; el tiempo de revisión no está presupuestado; la acción ocurre antes de la revisión; los revisores aceptan habitualmente los resultados sin verificarlos; y la responsabilidad sigue sin estar clara.
"Tenemos una política de IA"
Una política que no está conectada con el inventario, las aprobaciones, las pruebas, el monitoreo y los incidentes es una declaración de intenciones, no un sistema operativo.
Un plan mínimo de implementación de 30 días
| Período | Entregable |
|---|---|
| Semana 1 | Inventariar los sistemas actuales, las herramientas de los empleados, los pilotos, los agentes y las funciones de IA integradas |
| Semana 2 | Asignar responsables, clasificar riesgos, documentar los flujos de datos y las dependencias de proveedores |
| Semana 3 | Definir por nivel los requisitos de evaluación, aprobación, acceso, registro, incidentes y cambios |
| Semana 4 | Revisar los sistemas de mayor riesgo, suspender los usos sin respaldo y aprobar la hoja de ruta de corrección |
El resultado esperado no es una gran biblioteca de políticas.
Es un inventario; un mapa de riesgos; responsables con nombre propio; un estándar mínimo de control; una lista priorizada de correcciones pendientes; y un proceso de aprobación repetible.
Dónde la gobernanza genera ROI
La gobernanza suele tratarse solo como un costo asociado al riesgo.
Bien hecha, también reduce el desperdicio operativo porque evita: compras duplicadas de IA; pilotos interminables; consumo de API sin control; revisiones manuales que eliminan el ahorro esperado; dependencia de un proveedor; trabajo de integración repetido; despliegue de casos de uso sin valor medible; e incidentes que requieren correcciones costosas.
El objetivo económico no es el máximo control.
Es el modelo de control menos costoso que mantiene el sistema dentro de los límites de riesgo y rendimiento aceptables para la empresa.
En qué se resume la decisión
No empiece redactando una política de IA de cuarenta páginas.
Empiece con cinco preguntas: ¿Qué sistemas de IA ya influyen en el trabajo? ¿Qué resultados de negocio afectan? ¿Quién es responsable de esos resultados? ¿Qué evidencia demuestra que cada sistema es útil y está controlado de forma aceptable? ¿Qué casos de uso deben ampliarse, repararse, restringirse o detenerse?
La gobernanza de IA debe facilitar que los buenos sistemas escalen y que los sistemas débiles se descarten.
No debe existir para hacer imposible la experimentación.
Fill System ayuda a los equipos de empresas medianas a diseñar una gobernanza práctica mediante consultoría en IA y automatización de procesos y evaluaciones de Seguridad IT y Pentesting (inventario, clasificación de riesgos, asignación de responsables, controles de datos, criterios de evaluación y preparación ante incidentes).
Solicite un diagnóstico gratuito para identificar qué sistemas de IA necesitan controles de gobernanza antes de llegar a producción.
¿Está construyendo la gobernanza de IA para su equipo?
Solicite un diagnóstico gratuito y obtenga una imagen clara de qué corregir primero - sin compromiso.