«La empresa nativa de IA todavía no existe» es una tesis deliberadamente exigente, no el resultado de revisar todas las compañías del mundo. Una función generativa en el producto o licencias de copiloto para toda la plantilla no bastan. Bajo este criterio, la IA debe trabajar dentro de los derechos de decisión, presupuestos, registros operativos, controles y responsabilidades reales de la empresa.

Sin esa frontera, un mismo dato de adopción cuenta cuatro historias incompatibles. Producto celebra el uso de una función. Finanzas no ve cambios en plantilla ni margen. Seguridad detecta datos fuera de control. El empleado encuentra una herramienta corporativa que tarda semanas en aprobarse, mientras su cuenta personal funciona esta tarde. En proyectos de servicio y operaciones he visto la misma presentación recibir aplausos en una reunión y silencio en la siguiente. La discrepancia no estaba en el modelo: cada área estaba midiendo una empresa distinta.

Los datos actuales muestran mucha adopción y poco cambio profundo. En la encuesta global de McKinsey de 2025, el 88 % dijo que su organización usaba IA regularmente en al menos una función. Solo alrededor de un tercio había empezado a escalarla en toda la empresa. El 23 % escalaba algún sistema de agentes, pero ninguna función superaba el 10 %. La IA ya es habitual; una empresa rediseñada alrededor de ella, no.

Usar IA no equivale a operar mediante IA

Existe una objeción evidente al título. Un trabajo de INSEAD y Harvard Business School publicado en junio de 2026 estudia precisamente las «AI-Native Firms». Los autores clasificaron startups estadounidenses con capital riesgo y empresas de Y Combinator cuya primera financiación llegó entre 2020 y 2024. Frente a startups no centradas en IA de la misma industria y cohorte, las empresas nativas de IA eran un 25 % más pequeñas, tenían un 13 % más de proporción de ingenieros y cerca de un 15 % menos tanto de empleados junior como de directivos.

La página oficial de INSEAD titulada AI-Native Firms con la descripción de la estructura laboral de startups nativas de IA

Fuente: INSEAD, AI-Native Firms, consultada el 18-08-2026. Es un trabajo de 2026 que clasifica startups con descripciones de producto, ofertas de empleo y datos laborales.

Es una contraevidencia importante. Ya existen empresas cuyo producto se construye alrededor de la IA y su organización puede ser más pequeña y plana. La investigación no audita si aprobaciones presupuestarias en el ERP, acceso a datos de clientes, revisión legal, excepciones de pago y responsabilidad por incidentes forman un único sistema operativo controlado. Los propios autores distinguen un canal de producto, donde la IA vive en lo que la empresa vende, y un canal de proceso, donde cambia cómo se trabaja dentro de la firma.

Microsoft ofrece otra etiqueta útil. Su Work Trend Index de 2025 llama «Frontier Firm» a la organización basada en inteligencia bajo demanda y equipos de personas y agentes. Imagina «Work Charts» flexibles y orientados al resultado en lugar de organigramas rígidos. Microsoft habla de una forma emergente; combina una encuesta, señales de Microsoft 365 y datos de LinkedIn. Es una visión de mercado elaborada por un proveedor tecnológico, no un registro auditado de empresas que hayan reconstruido todos sus controles.

La distinción práctica es AI in the business frente a AI on the business. En el primer caso, la IA mejora un producto, una respuesta o un servicio. En el segundo, cambia cómo se reparten autoridad, dinero, información y responsabilidad. El primer estado ya es frecuente. La afirmación del título se refiere al segundo.

Los agentes chocan con las reglas que nunca llegaron al manual

El organigrama indica quién reporta a quién, pero no cómo termina realmente el trabajo. Un pago a proveedor puede parecer una sola aprobación de Finanzas. En la práctica, cierto contrato pasa antes por Legal, un importe alto necesita un mensaje del director y el cierre de mes usa otra hoja. Una coordinadora veterana conoce las tres excepciones. Si no está, el proceso se detiene.

Comparación entre el organigrama oficial y la ruta real del trabajo mediante excepciones, aprobaciones, atajos y reprocesos

Una persona puede preguntar. Un agente debe actuar con el mismo criterio cuando cambia el solicitante, se reorganiza el equipo o la excepción aparece de madrugada. La fuente de datos, condición de aprobación, regla de parada y responsable de escalado tienen que ser legibles. Cuando la práctica sale de la cabeza de alguien y entra en un sistema, surgen preguntas incómodas: ¿por qué decide solo esta persona?, ¿por qué un departamento tiene una vía privada?, ¿por qué se introduce dos veces el mismo contrato?

En ese momento, la implantación deja de ser solo técnica. La mayoría de los atajos no nacieron para proteger un feudo. Las personas los crearon para cubrir huecos de sistemas antiguos, cumplir plazos y evitar fallos. Con el tiempo también sostienen espacios de criterio y fronteras departamentales. Hacerlos visibles altera ese equilibrio. La resistencia es comprensible si el proyecto retira discreción o mueve responsabilidades sin decirlo.

Crear una filial «nativa de IA» rara vez resuelve el problema. El equipo nuevo se mueve rápido, pero no accede a datos de clientes, ERP, autoridad de compra, ingresos ni propietarios de proceso. Produce una demostración pulida y una buena presentación para el consejo; el flujo central sigue intacto.

Suele funcionar mejor un equipo interno pequeño con mandato real. Necesita presupuesto, capacidad de ingeniería y permiso para modificar un proceso completo junto con su responsable. Un comité puede aconsejar. El equipo de operaciones debe cambiar la ruta y responder por el resultado.

La IA en la sombra es incumplimiento y señal de lentitud

Imaginemos que aprobar una IA corporativa tarda tres meses, pero hay que clasificar 80 documentos de clientes esta semana. El empleado no esperará el plan estratégico. Abrirá una cuenta personal de ChatGPT o Claude, subirá los archivos o ejecutará un agente en su portátil. Los sistemas de la empresa no mostrarán ningún proyecto. El trabajo real terminará fuera. Eso es IA en la sombra.

La ruta desde una herramienta oficial lenta a una IA personal y un punto ciego de datos, frente a un espacio aprobado con identidad, registros y respuesta a incidentes

Microsoft Security define la IA en la sombra como el uso no autorizado y desprotegido de aplicaciones de IA, con riesgo de fuga de información sensible. Los controles de acceso y la prevención de pérdida de datos en el navegador son necesarios. Una lista de bloqueo más larga no elimina el plazo ni la carga de trabajo; puede limitarse a esconder mejor el atajo.

La ruta aprobada debe ganar tanto en utilidad como en seguridad. Hace falta un espacio autorizado, acceso breve al modelo adecuado y una forma documentada de conectar sistemas internos. Los permisos deberían tardar días, no trimestres. Estandarizar no obliga a usar un único modelo. Conviene unificar clasificación de datos, reglas de envío externo, puntos de aprobación humana y responsabilidad de soporte.

Los agentes también necesitan identidad propia y privilegio mínimo. Prestarles la cuenta de un empleado oculta quién o qué actuó. Un registro útil une solicitante, datos de origen, resultado de la decisión, acción de la herramienta y objeto modificado. Envíos externos, pagos, borrados y cambios de permisos deben detenerse antes de ejecutarse. Si algo falla, tiene que existir un responsable para parar, recuperar, notificar y revisar.

No es gobernanza decorativa. El perfil de IA generativa de NIST recomienda inventariar los sistemas, definir la supervisión humana, conservar registros, preparar la respuesta a incidentes y realizar revisiones posteriores. Para servicios de terceros también pide asignar la responsabilidad, ensayar planes y disponer de alternativas. Tratar un agente como participante de la organización exige adaptar identidad, acceso, registros y respuesta que ya se aplican a personas y sistemas.

Las unidades antiguas no captan el valor de los agentes

Incluso un entorno bien controlado tropieza con la medición. Las empresas llevan décadas presupuestando con plantilla, horas, licencias y número de entregables. Consultoría y legal facturan tiempo. El software cobra por usuario. La planificación convierte el trabajo en FTE. Si un agente completa en 40 minutos un análisis que requería 80 horas, hay valor, pero no una casilla honesta para registrarlo.

Cambio de horas, licencias, FTE y cantidad de entregables a trabajo completado, tiempo de ciclo, revisión humana y valor ajustado al riesgo

Mantener el modelo por horas castiga al proveedor que termina en 40 minutos. Cobrar las 80 horas antiguas hace que el cliente desconfíe. En diseño, «un entregable» dice poco cuando personas y agentes producen decenas de variantes. La licencia por asiento tampoco encaja con un agente que trabaja las 24 horas en varios procesos.

La proporción entre personas y agentes que propone Microsoft invita a pensar, pero no mide el resultado. Diez agentes pueden redactar borradores que una persona debe rehacer por completo. Aumentó la capacidad digital y el proceso no mejoró. Hay que seguir una solicitud hasta su final real: tiempo total, corrección humana, reprocesos, acciones no autorizadas, fallos de traspaso y coste de recuperación.

Empezaría el cuadro operativo con cuatro medidas. La tasa de finalización comprueba una condición de cierre definida por una persona. El tiempo de ciclo va desde la solicitud hasta el cierre real, no hasta la primera respuesta del agente. El tiempo de revisión humana cuenta lectura y reparación. El valor ajustado al riesgo descuenta costes de datos, permisos, fallos y recuperación. Las fórmulas cambiarán, pero la pregunta no: ¿bajaron el tiempo y el esfuerzo totales para resolver el problema del cliente?

Los primeros 90 días deben cambiar un flujo completo

No hace falta declararse nativo de IA el primer día. Un objetivo mejor es demostrar en 90 días que un flujo transversal puede terminar de forma segura. Reembolsos, alta de proveedores o aprobación de propuestas comerciales sirven porque tienen inicio y final claros y cruzan varios equipos. Una FAQ sencilla resulta más fácil, pero apenas prueba el modelo operativo.

Prueba de 90 días que avanza por observación, visibilidad, acción controlada y medición antes de ampliar

Durante las semanas uno y dos, conviene mirar pantallas y conversaciones reales en lugar de confiar en el manual. Se anotan la hoja privada, la aprobación por mensajería, el dato repetido y la excepción que solo recuerda una persona. En las semanas tres y cuatro se dibujan el dueño de la decisión, fuente de datos, excepción, control humano y condición de parada. Si no hay acuerdo, no se conecta el agente. El problema es la propiedad del proceso, no la automatización.

Las semanas cinco a ocho empiezan en un entorno autorizado con datos de solo lectura. El agente clasifica y prepara borradores. Mensajes externos, pagos, borrados y cambios de acceso siguen detrás de una aprobación humana. Se registran solicitud, entradas, decisión y acción. En las semanas nueve a doce se comparan finalización, ciclo, revisión, excepciones e incidentes. Los permisos de escritura solo aumentan si la mejora es real y la recuperación está probada.

Las condiciones de parada se fijan antes del piloto. No se amplía si el tiempo de corrección no baja, reaparece la misma excepción, nadie puede nombrar al responsable final o el registro no permite restaurar el estado anterior. Cuando un flujo termina con seguridad, quedan piezas reutilizables: contrato de datos, modelo de permisos, ruta de escalado y línea base de medición.

El equipo interno de IA necesita autoridad, no una marca llamativa. Debe poder gastar presupuesto, fijar normas de herramientas y cambiar procesos junto con sus propietarios. Un directivo aislado o un consejo asesor no ejecuta ese trabajo. Separar el equipo fuera de la empresa vuelve a alejarlo de datos y decisiones.

AI in the business es la mitad más accesible. AI on the business obliga a hacer visible el trabajo real, lograr que la vía oficial sea más rápida que la IA en la sombra, asignar identidad y responsabilidad a los agentes y cambiar las unidades heredadas de valor. No falta otro modelo de frontera. Falta reescribir reglas operativas que la empresa optimizó durante décadas para seres humanos.

Fuentes y referencias

Páginas públicas usadas para contrastar hechos reportados, documentación oficial, contexto de política, información de producto y afirmaciones que pueden cambiar.