Gobernanza de IA en la era del vibe coding: cuando el Shadow IT se convierte en Shadow AI

En mayo de 2026, la empresa israelí de ciberseguridad RedAccess rastreó 380.000 aplicaciones hechas con vibe coding y expuestas públicamente en internet; cerca de 5.000 de ellas guardaban secretos corporativos reales: los datos financieros de un banco brasileño, los registros de pacientes de un ensayo clínico en el Reino Unido, las conversaciones médico-paciente y los turnos del personal de un hospital, las grabaciones de clase y los datos de los alumnos de un colegio. Esas apps corrían en plataformas como Lovable, Replit, Base44 y Netlify. Según informa Axios, la mayoría no fueron hackeadas: las plataformas son públicas por defecto, nadie las cerró manualmente a privadas y los buscadores las indexaron directamente.

Quienes construyeron esas apps, en su mayoría, no saben que han filtrado nada — así es como se ve el Shadow IT en la era de la IA. Retenga ese término; volveremos a él enseguida.

---

Acerquemos el plano y veamos una versión más cotidiana.

Lunes por la mañana, 10:00. Carlos, director de Sistemas, recibe una llamada.

La página de campaña de socios de la empresa está caída; los clientes han pagado pero no han recibido el correo de confirmación. Carlos abre el panel para revisar los logs — y no encuentra el servicio. Después de preguntar a varias personas descubre la verdad: lo montó el equipo de marketing la semana pasada con Cursor y corre en la cuenta personal en la nube de alguien.

A partir de ese momento, el trabajo de Carlos cambia para siempre.

No es un caso aislado. El shadow IT (empleados que eluden el proceso formal de Sistemas para adoptar herramientas o montar sus propios sistemas) ha existido siempre, pero cuando las herramientas de IA permiten que marketing, ventas y RR. HH. escriban cada uno una aplicación en producción, su escala da un salto: de «un empleado se da de alta en un SaaS a escondidas» a «un empleado opera a escondidas un backend entero», y la caja de herramientas de gobernanza de IT tradicional no da abasto con esa magnitud. Este artículo trata de ese problema nuevo: cuando el Shadow IT se convierte en Shadow AI, cómo se desplaza con ello la frontera de seguridad de la empresa y cómo debe responder el director de Sistemas de primera línea (en pymes e industria tradicional también se le llama MIS o responsable de Sistemas; según el tamaño de la empresa, director de Sistemas o CIO).

Antes de seguir, conviene situar el alcance: la gobernanza de IA (AI governance) es enorme; el riesgo de modelo, la política de uso de IA, el human-in-the-loop y la rendición de cuentas están todos dentro. Este artículo se centra en una porción, la que aflora más rápido: cómo se mueve la frontera de seguridad de la empresa una vez que el vibe coding convierte el Shadow IT en Shadow AI. Va del fenómeno y sus causas hasta un marco de gobernanza que se puede seguir de verdad. Las demás porciones quedan para otro artículo.

TL;DR

• Marco: tres capas de gobernanza de IA: visibilidad → fronteras → auditoría. El orden importa; saltarse uno hace que el resto se caiga.
• Tesis: el sandbox se convierte en el nuevo perímetro de seguridad corporativo. No prohíba el vibe coding; tráigalo a un lugar que Sistemas pueda ver.
• Plan de acción: inventaríe lo que está corriendo ahora → abra un workspace aprobado → establezca una cadencia de auditoría.

El Shadow AI de la era del vibe coding: por qué es diez veces peor que el Shadow IT de antes

«Shadow IT» no es un término nuevo: Gartner lo convirtió en término propio durante la década de 2010. Para Sistemas es un punto ciego de gobernanza; para el empleado suele ser una decisión razonable «para sacar el trabajo adelante», y ambas posturas tienen su lógica. Acumulado a lo largo del tiempo, los datos, los procesos y los permisos de la empresa terminan dispersos en lugares que Sistemas no ve.

El Shadow IT de hace diez años era un empleado usando Notion a escondidas o pagándose Slack de su bolsillo. El trabajo del director de Sistemas era revisar las solicitudes de compra de SaaS, redactar la acceptable use policy y hacer inventarios periódicos. El dolor era «los datos acaban en lugares que no tocan», pero al menos esos lugares eran SaaS conocidos, con su informe SOC 2, su SLA y su ventanilla de soporte detrás.

El Shadow AI es la versión de la era de la IA del shadow IT, y el problema de fondo es exactamente el mismo: empleados poniendo datos sensibles en servicios de terceros no auditados por Sistemas. Lo que de verdad cambió es la naturaleza de ese «tercero»: antes era un SaaS hecho y conocido, ahora es una plataforma de vibe coding, o el backend y la base de datos que el propio empleado se monta. El contenedor pasa de «un servicio conocido y auditado» a «un sistema autoconstruido sin gobierno alguno», así que el riesgo, naturalmente, no es del mismo orden de magnitud. Comparémoslo de frente:

La diferencia más decisiva es la «controlabilidad». Antes, si los datos acababan por descuido en Notion, si un permiso se quedaba sin cerrar o si alguien de fuera entraba en la página, bastaba con cerrar el permiso o borrar la página y el riesgo, a grandes rasgos, quedaba contenido. Pero el Shadow AI «conecta» los datos sensibles a un sistema vivo: con que un único endpoint expuesto se delate, el atacante puede tirar del hilo y sacar la base de datos, la API y los demás datos internos que cuelguen detrás, y borrar una página ya no lo deshace. Esas 5.000 apps filtradas del principio eran justo eso: públicas por defecto, indexadas una a una por los buscadores.

Este fenómeno es más extendido de lo que parece; basta apilar unas cuantas cifras:

• Más del 40 % de las empresas sufrirá un incidente de seguridad o cumplimiento relacionado con shadow AI antes de 2030 (predicción de Gartner).
• El 71 % de los empleados ya ha usado herramientas de IA no autorizadas, y el 51 % lo hace cada semana (encuesta de Microsoft UK de octubre de 2025).
• Solo aproximadamente la mitad de los empleados de primera línea usa IA con regularidad de verdad. Tener acceso a GenAI es una cosa (siete de cada diez empleados en sectores maduros, menos de la mitad en sectores poco maduros) y usarla de verdad cuando se tiene es otra. El informe de BCG de septiembre de 2025 The Widening AI Value Gap (1.250 encuestados) llama a esa brecha entre «poder acceder» y «usarla de verdad» el «silicon ceiling» (techo de silicio).

Aunque solo la mitad use IA con regularidad, esa mitad ya está acumulando shadow AI que Sistemas no ve.

El vibe coding (término acuñado por Andrej Karpathy en febrero de 2025 para referirse a la práctica de generar código mediante lenguaje natural con LLMs) ha cambiado las reglas del juego: lo que hace el empleado sube un peldaño, de «darse de alta en un SaaS» a «operar por su cuenta un backend + base de datos + API». Las herramientas de IA (Claude Code, Cursor, GitHub Copilot) han extendido «la capacidad de escribir código» de los ingenieros a todo el mundo, pero «la responsabilidad de operar producción» no se ha extendido con ella. Saber escribirlo no significa saber que:

• Los secretos no deben vivir en el repo.
• Las copias de seguridad no se hacen solas.
• Cuando el tráfico se multiplica por diez hay que preparar algo antes.

El resultado es que la empresa acumula sin darse cuenta entre diez y treinta servicios en producción sin ningún registro de gobernanza. Recopilan datos de clientes, envían correos, se conectan al ERP interno, y el director de Sistemas no es capaz ni de decir sus nombres. Esta tensión entre la democratización de las herramientas y la ciberseguridad es la tensión de fondo que la gobernanza del vibe coding no puede esquivar.

Por qué el viejo perímetro de seguridad no aguanta lo que produce el vibe coding

Que el shadow AI haya crecido tanto se debe a tres fuerzas que ocurren a la vez, y cada una hace que las defensas tradicionales de Sistemas (firewall, IDP) no aguanten lo que producen los empleados.

El umbral de despliegue cae a cero, y la visibilidad se pierde

Lovable, Bolt, v0, Replit Agent y Claude Code convierten «escribe el código y corre directamente en el sandbox de la plataforma» en la acción por defecto: sin escribir Dockerfile, sin configurar servidor, sin solicitar cuenta. Para el empleado es una bendición; para el director de Sistemas es la pérdida total de visibilidad: no sabe cuántas apps de producción saltándose el proceso tiene la empresa corriendo, en qué cuentas personales corren ni de quién es la tarjeta que las paga.

La IA, para hacer algo realmente útil, necesita datos reales de la empresa

Para que la salida del vibe coding pase de demo a algo realmente útil, hay que alimentar a la IA con contexto real: lista de clientes, registro de pedidos, soluciones a problemas pasados, el wiki interno. Cuanto más contexto se da, más se ajusta al escenario lo que escribe la IA. Pero dar datos obliga a afrontar la anonimización, la privacidad y la responsabilidad de cumplimiento; y no darlos deja al empleado sin materia prima, con una salida que se queda en una versión de juguete que «parece que funciona pero no encaja con el escenario».

Los agentes y los sistemas que los empleados operan por su cuenta saltan el viejo perímetro de identidad

El Computer Use de Anthropic (octubre de 2024), Operator de OpenAI, Devin y otros permiten que el agente mueva por sí mismo el teclado y el ratón para escribir código y desplegarlo; y las apps de IA de los empleados también levantan a menudo por su cuenta un sistema que nunca pasa por un IDP (identity provider). En la era SaaS, el IDP gestionaba «quién puede iniciar sesión en qué sistema»; ahora lo rodean a la vez un nuevo actor (el agente) y una nueva superficie (las apps de producción que los propios empleados levantan).

El informe State of AI in the Enterprise 2026 de Deloitte señala que solo 1 de cada 5 (20 %) empresas tiene un modelo de gobernanza maduro para los agentes de IA autónomos, y apunta directamente la dirección: «Una gobernanza efectiva se integra en las estructuras de riesgo y supervisión ya existentes, no en funciones paralelas "en la sombra"». Es decir, la gobernanza ha de integrarse en la estructura de riesgo existente, no abrir un mecanismo paralelo en la sombra.

Estas tres fuerzas cambian la definición de «perímetro de seguridad corporativo». Dónde debe caer el nuevo perímetro y por qué la respuesta acaba apuntando al «sandbox» lo desarrollamos más adelante en una sección propia (ese término, igualmente, lo dejamos aparcado por ahora).

Las tres señales de que el Shadow AI se ha descontrolado: crisis de visibilidad, de fronteras y de auditoría

Cuando el director de Sistemas empieza a pronunciar estas tres frases, el problema del Shadow IT ya ha llegado al punto en que toca actuar:

Señal 1: la crisis de visibilidad

«No sé cuántas aplicaciones tiene la empresa corriendo ahora mismo.»

Las apps de IA de los empleados viven en cuentas distintas, tarjetas distintas y PaaS distintos; Sistemas no tiene inventario, y cada vez que algo se rompe el primero al que llaman es a él — pero ni siquiera sabe cómo se llama esa cosa.

Señal 2: la crisis de fronteras

«Se marcha la semana que viene, pero no sé qué datos de la empresa usa lo que ha construido.»

El empleado le enseñó a la IA la cadena de conexión a la base de datos de clientes, la escribió en el código y todo corre en su cuenta personal. Cuando esa persona se va, la empresa no tiene ningún mecanismo para hacerse cargo de ese sistema — ni forma de revocarle el acceso.

Señal 3: la crisis de auditoría

«A fin de año hay que pasar la auditoría, pero estas cosas quedan fuera de mi control.»

Los clientes piden SOC 2, los concursos públicos exigen ISO, el sector requiere pasar revisiones de seguridad — y el auditor preguntará «¿logs de acceso? ¿copias? ¿registro de cambios? ¿quién puede modificar y quién puede ver?». El director de Sistemas no tiene respuestas.

El dilema de la gobernanza de IA en la empresa: el director de Sistemas, atrapado entre adopción y control de riesgos

Empecemos por una cifra de referencia: la encuesta global The State of AI 2025 de McKinsey (105 países, 1.993 encuestados) encontró que el 88 % de las organizaciones ya usa IA con regularidad en al menos una función de negocio, pero solo el 18 % ha creado un comité de gobernanza de IA a nivel corporativo. Es decir, en más del 80 % de las empresas los empleados ya usan IA, pero la estructura de gobernanza todavía no ha crecido. El dilema del director de Sistemas nace precisamente de esa brecha.

Para entender el aprieto del director de Sistemas, miremos primero la presión que viene de las dos capas de arriba.

La vista desde el CEO: la ansiedad por la adopción de IA

En estos dos años, 2025-2026, casi todos los dueños de empresa están con ansiedad por la IA: la competencia la está usando, la prensa la persigue, los empleados preguntan. La reacción instintiva es un mandato de arriba abajo: «El año que viene seremos AI-first», «cada departamento entrega una app de IA», «el departamento que no sepa usar IA será reevaluado». El objetivo es que la empresa parezca que se mueve y no quede barrida. Pero entre empujar de arriba abajo y la adopción real hay un abismo.

Duolingo es el caso público canónico de ese abismo: el 28 de abril de 2025, su CEO Luis von Ahn anunció en LinkedIn una estrategia «AI-first», ir retirando a los contratistas que la IA pudiera reemplazar y meter «saber usar IA» en las contrataciones y en la evaluación del desempeño; según TechCrunch, dos días después del anuncio la empresa publicó 148 cursos generados con IA, doce años de desarrollo curricular comprimidos en menos de uno. La reacción de la comunidad estalló enseguida: los usuarios cancelaron suscripciones, borraron la app, una avalancha de reseñas negativas en TikTok; Duolingo eliminó todas sus publicaciones en TikTok e Instagram y se quedó en silencio una temporada. Unas cuatro semanas después, von Ahn se retractó públicamente en LinkedIn de lo que había dicho; Fortune cita sus palabras textuales: «No veo la IA como algo que sustituya lo que hacen nuestros empleados», y declaró que las contrataciones seguirían al ritmo de siempre; en la conference call del Q2 2025 también reconoció que los comentarios sobre IA habían dejado el crecimiento de DAU en la parte baja de lo previsto (40 % interanual, frente al 60 % del mismo periodo del año anterior).

Este patrón se repite en muchas empresas cuando empujan la IA de arriba abajo. Fortune informó de que Klarna sustituyó a 700 agentes de atención al cliente por IA y medio año después volvió a contratar personas: el mismo guion.

La descripción que más uso yo:

Que se use no es lo mismo que adoptarla, y poder adoptarla no significa poder sacarle valor. — Ling Wu

Que un empleado abra Cursor cada día (incluso para preguntarle qué comer) no es adopción real de la IA en el flujo de trabajo; y aunque llegue a montar algún sistema pequeño con ella, eso tampoco es productividad medible: la mayoría de las empresas todavía no tiene una vara para medir si la IA está mejorando o no la productividad. En medio hay dos brechas, «treatment vs deployment» y «deployment vs utilization», y ambas atascan.

La vista del director de Sistemas: el dilema entre control de riesgos y flexibilidad

En esta estructura de sándwich, el director de Sistemas tiene que responder a la vez al «queremos ser AI-first» del CEO (empujar la adopción) y gestionar el riesgo de gobernanza que arrastra la proliferación del vibe coding (mantener la estabilidad). Es un trabajo de hacer enable + control al mismo tiempo: si cualquiera de los dos lados pesa demasiado, vuelca.

Las dos reacciones extremas correspondientes son ambas versiones de no aguantar los dos lados:

Reacción 1: prohibirlo

«A partir de ahora los empleados no pueden usar IA para escribir aplicaciones por su cuenta; todo pasa por el proceso de solicitud de Sistemas.» El resultado es obligar a todo el mundo a usar herramientas que les atan las manos: las que Sistemas aprueba suelen quedar muy por detrás en capacidad respecto a lo que usan los builders fuera, y no llegan a hacer lo que el empleado quiere de verdad; el empleado no va a parar porque Sistemas se oponga (el CEO acaba de decir «usad IA para ser más eficientes»), así que sigue construyendo y lo esconde en lugares más opacos. Prohibir amplifica la crisis de visibilidad y la convierte en una crisis de clandestinidad, y deja al director de Sistemas como «el cuello de botella que frena la IA» a ojos del CEO.

Reacción 2: ignorarlo

«Total, la auditoría aún no ha llegado, ya me ocuparé.» Se deja correr, pero al dejarlo el problema crece solo — compañeros que no dominan los frameworks de frontend ni la elección de base de datos eligen cada uno sus herramientas, y tres personas pueden acabar usando tres frameworks distintos y cuatro bases de datos distintas; con diez sistemas creciendo a la vez, la empresa se queda con un montón de combinaciones de tech stack esperando a que alguien las recoja. Cuando el auditor por fin llama a la puerta, el director de Sistemas no solo carga con la pesadilla de la auditoría, sino también con todas esas combinaciones de tech stack que en su día se dejaron sin tocar, estallando a la vez.

El dolor del sándwich, dicho sin rodeos, es: el CEO solo mira si la adopción avanza, el empleado solo se preocupa de si lo que ha escrito corre, pero el riesgo (fuga de datos, brechas de cumplimiento, fracaso en la auditoría) y la «deuda» de mantener los sistemas (quién los arregla, quién hace las copias, quién cambia de herramienta) quedan todos sobre los hombros de una sola persona, el director de Sistemas — y a nadie le importa lo que él aguanta.

La dirección correcta es la tercera vía: traer la salida de la IA a un entorno que Sistemas pueda ver, sin impedir que los empleados sigan construyendo. Dicho de otro modo: el sandbox se convierte en el nuevo perímetro de seguridad corporativo (en la comunidad de seguridad anglosajona se resume como «sandbox is the new perimeter»).

Desde este ángulo, el director de Sistemas hace a la vez enable (los empleados siguen usando IA) + control (Sistemas puede verlo y gestionarlo): responde al mandato de arriba abajo del CEO, resuelve el riesgo de gobernanza y no interrumpe el flujo de trabajo diario del empleado. Qué es exactamente un sandbox y por qué solo en estos uno o dos años se ha convertido en la respuesta por defecto para el perímetro de seguridad corporativo lo desarrollamos en una sección más adelante.

Marco de gobernanza del vibe coding: las tres capas de visibilidad, fronteras y auditoría

Para tratar la gobernanza del vibe coding como un asunto serio a nivel corporativo, el sector ya cuenta con varios estándares que abordan el tema:

• NIST Cybersecurity Framework 2.0 (2024): 6 funciones: Govern, Identify, Protect, Detect, Respond, Recover. Cubre todo el ciclo de vida de la cyber governance, desde la identificación del riesgo hasta la respuesta a incidentes.
• NIST AI Risk Management Framework (NIST AI 100-1, 2023): 4 funciones: Govern, Map, Measure, Manage. La referencia para gobernar el riesgo de IA como un riesgo empresarial.
• ISO/IEC 42001:2023: el primer estándar internacional de sistemas de gestión de IA, alineado con frameworks de ISMS ya existentes como ISO 9001 e ISO 27001.

Cómo se alinean estos estándares entre sí, por dónde debe empezar a aterrizarlos una pyme y qué compensaciones implica su implementación (cómo encajar en los propios procesos términos de gobernanza de IA como quality gate, operational debt, technical debt o paved path) se desgranará por completo en otro artículo.

Este artículo destila esos estándares en tres capas, en un marco que permite identificar rápido los problemas de los escenarios de vibe coding: visibility, boundaries, audit. El orden importa, y cada capa resuelve un problema distinto:

Capa 1: Visibilidad (visibility)

El trabajo más básico es traer todas las apps de IA a un mismo lugar desde donde mirarlas. Un único punto de facturación, un único panel que muestre todos los despliegues, un único log de auditoría que diga quién cambió qué.

Lo concreto que hay que hacer es: darle al empleado un entorno aprobado (un workspace que paga la empresa, una cuenta gestionada por la empresa) y animarle a desplegar ahí sus apps de IA. El empleado sigue haciendo vibe coding, Sistemas lo ve. Sin visibilidad, las dos capas siguientes son imposibles.

Aterricemos en una escena concreta: Carlos abre el workspace de IT de la empresa y de un vistazo ve doce servicios en fila: marketing-membership-page (de marketing, la semana pasada Chen tocó una env var), hr-interview-scheduler (de RR. HH., corre en la región de Asia, este mes lleva 2,3 GB), sales-customer-cleanup (de ventas, dos semanas sin desplegar)... cada uno con su owner, su último despliegue, su región y su coste. Carlos no necesita preguntarle a nadie; el panel responde directamente «qué está corriendo ahora».

Capa 2: Fronteras (boundaries)

La visibilidad resuelve «no sé qué está corriendo»; las fronteras resuelven «no sé qué datos usa».

Lo concreto que hay que hacer son tres cosas:

• Aislamiento de entornos: dev / staging / producción, cada entorno con permisos independientes, para que un experimento no golpee por error datos de producción.
• Gestor de secretos compartido: las credenciales viven en un único almacén gestionado; la IA ve la referencia pero no llega al texto plano.
• Automatización de la revocación de asientos: cuando un empleado se va, todas las vías de acceso se revocan de un golpe, sin jugar al gato y al ratón en cinco paneles de PaaS.

La app de IA del empleado puede conectarse a los datos internos, pero las credenciales no entran en el prompt de la IA y, cuando el empleado se va, el acceso se corta solo.

Aterricemos en una escena concreta: Chen, que se marchó la semana pasada, había construido customer-feedback-collector, que corría en su propia cuenta de GitHub OAuth. Carlos pulsa una vez «eliminar collaborator» en el workspace: el entorno de producción de ese servicio pasa automáticamente a «sin reclamar», todas las vías de acceso se revocan y la facturación se traslada a la cuenta principal de la empresa, sin que RR. HH. tenga que pedirle nada a Chen.

Capa 3: Auditoría (audit)

Los logs de auditoría dicen quién desplegó qué, quién cambió qué env var, quién consultó qué log; la propiedad de los recursos da respuesta a «de quién es este servicio»; el historial de despliegues hace que el registro de cambios no dependa de que el empleado lo guarde por su cuenta.

Esta capa solo resuelve la parte de gobernanza, no la certificación de cumplimiento en sí. Cuando el cliente necesita pasar ISO 27001, ENS o los esquemas regionales que corresponda, hay que mapear las herramientas integradas del plan al marco de auditoría: eso suele requerir un consultor o una revisión de gobernanza, y no es algo de lo que deba encargarse un PaaS.

En España y la UE ya existe un marco de referencia escrito directamente para esto. El Reglamento (UE) 2024/1689, Reglamento de Inteligencia Artificial (en vigor desde el 1 de agosto de 2024, plenamente aplicable el 2 de agosto de 2026) define en sus artículos 9, 10, 12 y 15 obligaciones concretas de gestión de riesgos, gobernanza de datos, registros de eventos y robustez técnica para los sistemas de alto riesgo, y la Agencia Española de Supervisión de Inteligencia Artificial (AESIA) es la autoridad nacional que supervisa su aplicación. Las orientaciones de la Agencia Española de Protección de Datos (AEPD) sobre IA generativa cierran el círculo articulando cómo encajan el RGPD y el Reglamento de IA en la práctica. Lo que la auditoría pide, «quién tomó qué decisión en qué fase», los logs de auditoría de un PaaS solo lo cubren a medias; la otra mitad depende de que el proceso lleve estos requisitos hasta dentro de la organización.

Pongamos un escenario concreto: un empleado, con un flujo de trabajo montado por él mismo (una pequeña herramienta escrita con Claude Code + n8n conectado a la API del wiki interno), quiere generar automáticamente contenido de respuesta de cara al cliente; para que la IA responda con más precisión, mete los datos del wiki interno en el prompt, pero los datos del wiki interno no están del todo anonimizados: listas de personal, importes de acuerdos, registros de quejas anteriores de clientes, todo está ahí. La IA no distingue por sí sola qué es público y qué no, así que parte de esos datos privados sale, mezclada dentro de «la respuesta que ve el cliente».

Dejemos a un lado la cuestión de la rendición de cuentas y los pleitos de este escenario. En el fondo, el núcleo de la capa de auditoría está en el diseño del proceso: si se coloca o no un checkpoint en el momento en que la IA toca datos sensibles. Que el auditor llegue y pueda enseñar logs es lo mínimo; el diseño del proceso es lo que de verdad protege. En la era de la IA, nadie sabe cuándo aparecerá el próximo incidente público de gobernanza; ir aterrizando poco a poco las tres capas de gobernanza es la clave para convertir este tipo de riesgo de «desastre» en «un incidente menor que se puede atajar a tiempo».

Una de las implementaciones concretas es empujar la primera barrera hacia el lado del empleado: antes de desplegar, pasar una ronda de escaneo de secretos, una comprobación de las rutas de fuga de datos sensibles y alertas de dependencias sin actualizar, para que el propio empleado lo corrija; Sistemas hereda un producto que ya ha pasado el primer filtro. En el mercado ya hay bastantes servicios que automatizan esta barrera. Cómo configurar los checkpoints y cómo establecer el human-in-the-loop es el tema de otro artículo.

Poner las tres capas visibility → boundaries → audit juntas resuelve problemas de niveles distintos; pero las tres comparten un mismo requisito previo: hace falta un contenedor que Sistemas pueda ver y gestionar donde puedan aterrizar. La sección anterior, El dilema de la gobernanza de IA en la empresa, ya adelantó esta respuesta: el sandbox se convierte en el nuevo perímetro de seguridad corporativo. La siguiente sección desarrolla por qué esta respuesta solo ha emergido en estos uno o dos años y qué ha cambiado.

El nuevo perímetro de seguridad corporativo del Shadow IT: el sandbox

Hasta ahora hemos ido lanzando el «sandbox» como respuesta; aquí toca explicar formalmente qué es.

El concepto no es nuevo: los navegadores tienen sandbox (una página web no puede acceder a tus archivos locales), iOS tiene sandbox (cada app solo toca sus propios datos), y los runtimes de los distintos lenguajes de programación tienen también su propio diseño de aislamiento, todo ello con al menos una década a sus espaldas. Lo nuevo es que en estos uno o dos años se ha empujado al centro del debate de gobernanza de IT y se ha convertido en la respuesta por defecto para el perímetro de seguridad corporativo, porque esas tres fuerzas de antes (umbral de despliegue a cero, la IA necesita datos reales, el agente rodea el IDP) atravesaron las viejas defensas.

El sandbox es la respuesta común a esas tres fuerzas: el empleado sigue desplegando sin fricción, pero corriendo en un sandbox que Sistemas puede ver; la IA solo ve la porción de datos preparada dentro del sandbox y los campos sensibles se gestionan antes de que los datos salgan, así que Sistemas no tiene que revisar cada prompt caso por caso; y el sandbox recoge a la vez las acciones del agente y los sistemas de los empleados como un único límite de ejecución. Empresas especializadas en sandbox para agentes como E2B, Daytona, CodeSandbox SDK, Modal o Beam han surgido rápido en los últimos doce meses, precisamente al ver esta brecha.

¿Dónde corre el sandbox en sí?

El sandbox tiene tres opciones para aterrizar: usar el sandbox integrado de la plataforma, autoalojarlo por completo o un sandbox gestionado (el modelo PaaS). Reconocer que el sandbox es la respuesta es solo el primer paso: dónde corre el sandbox en sí, quién lo gestiona y quién lo arregla cuando se rompe es la decisión que todos los directores de Sistemas están evaluando en 2026, y las tres vías tienen sus compensaciones:

• Usar el sandbox integrado de la plataforma (el default de Lovable / Bolt / v0, etc.): sencillo, pero los datos y la salida quedan atados al vendor, Sistemas no consigue un inventario y la factura suele seguir cargada a la tarjeta personal del empleado.
• Autoalojarlo por completo: técnicamente controlable, pero hay que mantener un equipo de infra dedicado a ello. El empleado hace vibe coding para esquivar el proceso de Sistemas, y Sistemas, para acorralar el vibe coding en un sandbox, acaba gestionando un sistema más, así que el coste no tiene por qué salir más barato.
• Sandbox gestionado (el modelo PaaS): elige la nube, la región y el alcance de la soberanía del dato que quieras, pero la operación se la deja a la plataforma.

Esta decisión no se puede aplazar: el vibe coding de los empleados no te va a esperar.

Si juntamos esas tres fuerzas, la definición del perímetro de seguridad de la empresa lleva todo este tiempo desplazándose: antes de los 2000 era la era del cortafuegos, que guardaba «quién puede entrar en la red de la empresa»; de 2010 a 2024 pasó a ser IDP / SaaS, que guardaba «quién puede iniciar sesión en qué sistema»; de 2024 en adelante, en la era del vibe coding, lo que hay que guardar se convierte en «en qué sandbox corre lo que producen el empleado y el agente».

Este sandbox traza, alrededor de la libertad del empleado, un perímetro que Sistemas puede ver. Los empleados (y los agentes que esos empleados levantan) siguen haciendo vibe coding dentro; Sistemas no revisa código, no prohíbe herramientas, no rehace el trabajo de nadie; solo necesita mantener el sandbox en sí: dónde está, quién puede entrar, qué está corriendo, cuánto consume.

Este ángulo es una liberación para el director de Sistemas: su papel pasa de «prohibir que el empleado haga X» a «darle al empleado un lugar donde hacer X». El primero le convierte en bloqueador, el segundo en habilitador; el mismo director de Sistemas, y la diferencia está solo en qué línea elige defender.

Tres pasos para que el director de Sistemas aterrice la gobernanza del vibe coding

Si usted es director de Sistemas y su empresa acaba de entrar en la fase del vibe coding:

Paso 1: haga un inventario. Pregunte a cada departamento «¿habéis usado IA últimamente para construir algo que esté corriendo?». El resultado suele asustar; escríbalo todo, esa es su línea base de visibilidad.

Paso 2: abra un workspace aprobado, con despliegue centralizado, facturación compartida, logs de auditoría y gestión de asientos de una sola vez. Este ecosistema se divide a grandes rasgos en tres capas, con opciones habituales:

• Capa de identidad y permisos: Okta, Entra ID (antes Azure AD), Auth0, JumpCloud, GitHub Enterprise SSO, que gestionan «quién puede iniciar sesión en qué sistema».
• Capa de integración de despliegue + facturación + auditoría: Fly.io organizations, Heroku Teams, Render Teams, Vercel Teams, Zeabur Team Plan, que gestionan «dónde corre cada cosa, quién la ve, quién la paga».
• Capa de automatización del control de riesgos y el cumplimiento: Vanta, Drata, Secureframe, Datadog Cloud Security, que gestionan «la preparación de auditorías y las alertas de anomalías».

Un stack completo suele combinar dos o tres capas. Lo importante no es la elección concreta, sino lograr que las apps de IA que ya tienen los empleados se migren aquí y que las nuevas corran aquí por defecto.

Paso 3: establezca un pasillo de auditoría. Aunque no tenga que pasar una ISO o un SOC 2 formales, haga cada trimestre una revisión de los logs de auditoría y confirme que todos los servicios en producción tienen owner; este hábito le salvará la vida cuando llegue una auditoría de verdad.

Distintos sectores afrontan la gobernanza de la IA cada uno con su propia lectura. El motor de dos personas de una productora de comedia es un caso reciente: Sunny lidera la gestión y Feng se encarga de la implementación de ingeniería, llevando las tres capas de gobernanza anteriores al flujo de trabajo diario.

Traer los sistemas de vibe coding al marco de gobernanza de IT

Volvamos a la historia de Carlos; han pasado tres meses.

Cuando recibió aquella llamada de «la página de campaña de socios está caída», Carlos ni siquiera sabía cómo se llamaba el servicio. Ahora abre el workspace de IT de la empresa y lo que ve es un panel unificado: la página de campaña de socios de marketing está aquí, la herramienta de organización de datos de clientes de ventas allá, el programador de entrevistas de RR. HH. también. El estado de despliegue de cada servicio, quién tocó la última env var, cuántos recursos consume, en qué región corre, todo en la misma pantalla.

Los empleados siguen escribiendo cosas con Cursor, y las nuevas apps de IA se despliegan por defecto en este workspace. Carlos no necesita perseguir a cada departamento preguntando «¿qué habéis hecho últimamente?»; el panel ya responde a esa pregunta. Cuando algo se rompe, sabe a quién buscar, sabe dónde corre el servicio correspondiente y sabe dónde está la frontera de los datos.

No le ha prohibido a nadie usar IA; lo que ha hecho es montar bien el sandbox, dejando que el vibe coding de los empleados ocurra de forma natural dentro de este espacio aprobado.

Eso es la gobernanza de IT en la era del vibe coding: una vez que se diseña claramente dónde pueden correr los empleados, quién tiene permitido escribir deja de ser el problema.

Si quiere ponerse manos a la obra directamente a levantar el sandbox y traer el vibe coding de los empleados a un entorno que Sistemas pueda ver, Zeabur Team Plan está diseñado para hacer exactamente esto.