Cibernética de empresas de IA: el nuevo marco formal

Un marco matemático para entender tu empresa de IA

Un trabajo de investigación publicado como preprint propone algo inusual: modelar una empresa de inteligencia artificial como un sistema cibernético abierto, dependiente de recursos, donde las observaciones, los procedimientos de aprendizaje, las acciones de despliegue y las reglas de gobernanza cierran varios bucles de retroalimentación. La idea de fondo no es nueva —viene de la cibernética de Wiener, Ashby y Beer— pero el paper la lleva a un nivel de formalización matemática que hasta ahora no se había aplicado a firmas de IA.

¿Por qué importa a un founder? Porque detrás de cada startup de IA hay exactamente eso: datos que alimentan modelos, modelos que generan productos, productos que producen más datos, y decisiones de gobernanza que regulan quién puede cambiar qué. Lo que el paper hace es darle a esa realidad un lenguaje formal que permite distinguir, por ejemplo, entre dos empresas que producen los mismos outputs pero aprenden a ritmos distintos, o entre dos sistemas con la misma arquitectura pero distinta capacidad de observación.

Qué propone exactamente el paper

El trabajo define una empresa de IA como un sistema certificado con varios componentes tipados: roles humanos, datos y procedencia, modelos y parámetros, memoria del optimizador, controladores, recursos y gobernanza. Cada estado del sistema debe venir acompañado de un certificado de admisibilidad —una prueba de que cumple las reglas declaradas— y cada actualización debe preservar esa admisibilidad. La propuesta se apoya en herramientas matemáticas densas: teoría de homotopía, ∞-topos, lentes (lenses) y jets diferenciales, según el texto original.

El autor del paper no presenta esto como una ley empírica de la industria, sino como un programa de investigación. Las hipótesis de partida son condicionales: que los rastros de empleados y clientes pueden volverse datos de entrenamiento productivos, que la retroalimentación cambia el comportamiento que se mide, y que la integración de datos crea incentivos de consolidación. El modelo no dice que toda empresa de IA haga todo esto; ofrece un lenguaje para preguntar si lo hace y bajo qué condiciones.

Un resultado concreto que sí establece el paper: bajo una arquitectura de red neuronal diferenciable con flujo de gradiente, se puede derivar exactamente un kernel tangente neuronal dependiente del optimizador. Esto significa que la velocidad de aprendizaje de tu modelo no es solo función de los datos, sino del optimizador que usas y de la geometría del espacio de parámetros. Dos modelos pueden predecir lo mismo y aprender a velocidades muy distintas por una simple reparametrización.

El bucle que toda empresa de IA ya tiene (aunque no lo llame así)

El paper incluye un diagrama de arquitectura de retroalimentación a nivel de firma con seis nodos: personas y entorno, rastros y datos, aprendizaje y evaluación, despliegue y acción, gobernanza y recursos. Las flechas no son decorativas: cada una tiene un interfaz tipado y una interpretación operacional explícita. Quien ha operado un producto de IA reconoce ese grafo de inmediato, porque es lo que pasa cuando un usuario genera telemetría, esa telemetría entrena un modelo, el modelo actualiza el producto, y el equipo decide si ese cambio cumple políticas internas y externas.

Lo que el marco añade es precisión sobre tres puntos que los founders suelen manejar por intuición:

• Cobertura de rastreo. Qué fracción de la actividad relevante de la empresa queda efectivamente capturada como dato útil para aprendizaje. La mayoría de startups subestima esto: su pipeline de datos no observa ni el 10% de las señales que podrían mejorar el producto.
• Desigualdad entre observación, intervención y gobernanza. No es lo mismo poder ver un dato que poder actuar sobre el sistema que lo produce, y no es lo mismo poder actuar que tener autoridad formal para cambiar las reglas del juego. El paper postula que estas capacidades no crecen juntas por defecto: comprar más sensores no te da gobernanza, y tener gobernanza no te garantiza buena observación.
• Conservación de certificados bajo iteración. Si cada actualización del sistema preserva sus invariantes declarados, entonces toda secuencia de actualizaciones también los preserva. En lenguaje de founder: si tu proceso de release mantiene propiedades como "no expone datos de usuario" o "no degrada el modelo por debajo de X umbral" en cada paso, las mantiene en el agregado. Esto es trivialmente cierto para un solo ingeniero, pero se rompe rápido en organizaciones con múltiples equipos tocando el mismo sistema.

Por qué este tipo de formalización está ganando tracción

No es el único paper que intenta aplicar herramientas matemáticas abstractas al análisis de sistemas de IA. En diciembre de 2025, un equipo de la Universidad de Yale, la Universidad de Bolonia, la Universidad de Tokio City y CONICET en Argentina publicó un análisis categórico de grandes modelos de lenguaje en arXiv, usando la categoría de relaciones para distinguir formalmente entre la ruta epistémica humana y la ruta computacional de un LLM, y concluir que las alucinaciones son fallos estructurales de entailment, no bugs corregibles, según el artículo de Floridi y coautores.

Lo que une ambos trabajos es la convicción de que los enfoques puramente ingenieriles o puramente filosóficos se quedan cortos. Para entender qué hace una empresa de IA —y qué puede salir mal—, necesitas un lenguaje que hable simultáneamente de interfaces, estados, certificaciones y dinámicas de optimización. Las herramientas que el paper original menciona (lentes, jets, ∞-topos) son densas, pero el problema al que apuntan es concreto: cada vez más founders están gestionando sistemas cuyo comportamiento emerge de interacciones entre muchos componentes optimizándose en paralelo.

Qué significa esto para tu startup

No necesitas aprender teoría de categorías para aprovechar las ideas del paper. Lo que sí puedes hacer hoy:

• Audita tu bucle de retroalimentación real, no el del pitch. Dibuja las seis cajas del paper (personas, datos, aprendizaje, despliegue, gobernanza, recursos) con nombres concretos de tu empresa. ¿Dónde se rompe el flujo? La mayoría de founders descubren que su "pipeline de datos" es en realidad tres pipelines distintos con tres propriétaires distintos que no se hablan.
• Separa lo que observas de lo que controlas y de lo que gobiernas. El paper postula que estas tres capacidades son independientes. Hazte la pregunta explícita: ¿qué datos estás viendo que no puedes usar para mejorar el producto? ¿Qué palancas tienes pero sin mandato formal? ¿Qué decisiones tomas sin datos suficientes? Las tres listas suelen revelar desalineaciones que cuestan dinero.
• Trata tus invariantes como certificados, no como buenas intenciones. Si tu sistema dice "no entrenamos con datos de clientes europeos sin consentimiento", pregúntate si eso se verifica automáticamente en cada update o si confías en que el equipo lo recordará. El paper muestra que la diferencia entre las dos cosas se acumula con cada release.
• Cuidado con la ilusión de equivalencia. El ejemplo del paper es elocuente: dos funciones con la misma salida realizable pueden tener kernels de aprendizaje distintos y, por tanto, dinámicas temporales muy diferentes. Lo mismo aplica a productos: dos SaaS con la misma feature list observable pueden tener loops de mejora radicalmente diferentes, y por tanto valoraciones y trayectorias distintas.

El límite honesto del enfoque

El propio paper es explícito en lo que no afirma: que toda empresa de IA recoja todos los rastros disponibles, que deba emerger un solo actor dominante, o que la concentración económica sea una consecuencia matemática del marco. La cibernética organizacional que propone es una herramienta de análisis, no una profecía. Para un founder, eso es bueno: significa que el marco describe un espacio de diseño, no un destino inevitable. Las decisiones sobre qué datos capturar, qué optimizadores usar, qué gobernanza implementar y qué certificaciones exigir siguen siendo tuyas.

Si algo de esto te resuena, vale la pena leer el paper original con tiempo. No para implementar las matemáticas, sino para entender por qué un investigador eligió ese nivel de formalización: porque el problema que describes —gestionar una empresa cuyo producto aprende de sus usuarios y cuyos cambios afectan a esos mismos usuarios— ya no cabe en los marcos conceptuales del management tradicional.

Fuentes

• Cybernetics of AI Companies (fuente original)
• A Categorical Analysis of Large Language Models and Why LLMs Circumvent the Symbol Grounding Problem — arXiv, diciembre de 2025