El futuro del software empresarial

Cómo la IA puede ayudar a la ingeniería de sistemas y la criptografía verificar afirmaciones concretas

Publicado por Polity | julio de 2026
Autores: Alexandre Kotcherguine, Vision Officer & Investor, Polity;
Kevin Riedl, Managing Partner, Wavect GmbH

Este artículo se revisó por completo el 2 de septiembre de 2026 frente a investigación pública, documentación oficial, encuestas sectoriales e informes profesionales. Varias tecnologías siguen en una fase temprana. Las afirmaciones de proveedores sobre rendimiento y adopción se identifican como tales; las cifras son instantáneas, no garantías. Nada de esto constituye asesoramiento profesional, jurídico o de inversión.

Resumen ejecutivo

El software empresarial puede perder coherencia al fragmentarse y convertirse en un monolito distribuido. El análisis asistido por IA puede reducir parte del trabajo necesario para mantener una visión del sistema completo. La investigación actual sobre MBSE aún exige supervisión humana y no demuestra modelado autónomo a escala empresarial. Las pruebas criptográficas y los registros resistentes a manipulaciones pueden hacer comprobables computaciones y registros seleccionados. No demuestran una arquitectura completa, la veracidad de los inputs, la idoneidad del modelo ni compliance. Pueden complementar auditorías y contratos en fronteras concretas; su economía y orden de adopción dependen de la carga.

La era de la fragmentación

El movimiento dominante en arquitectura empresarial durante la década de 2010 tenía una motivación clara y en gran medida razonable. Los monolitos se habían convertido en «grandes bolas de barro»: fuertemente acoplados, difíciles de cambiar y lentos de desplegar; los microservicios prometían una salida: descomponer la aplicación alrededor de capacidades de negocio, dar a cada servicio un despliegue independiente y permitir que los equipos avanzaran en paralelo. Al principio funcionó para muchas organizaciones. Pero el patrón se adoptó ampliamente como opción predeterminada en lugar de como una elección meditada, y el resultado, repetido en todo el sector, fue un modo de fallo característico al que los profesionales acabaron dando un nombre preciso. El «monolito distribuido» tiene, según una descripción muy citada, la complejidad operativa de los microservicios sin la independencia arquitectónica: servicios separados físicamente pero acoplados lógicamente, dependientes de los esquemas de base de datos de otros, que requieren despliegues sincronizados y se llaman entre sí en largas cadenas, de modo que un cambio en uno rompe otros tres y cada release se convierte en un ejercicio de coordinación (1). La organización ganó más repositorios, más pipelines, más logs, más modos de fallo y más overhead de gobernanza, sin ganar la capacidad de avanzar más rápido.

La encuesta oficial de CNCF no demuestra un retorno sectorial de microservicios a monolitos. En 2024 comunicó un 89 por ciento de adopción cloud-native; la adopción de service mesh pasó del 50 por ciento en 2023 al 42 por ciento en 2024 ante problemas de complejidad operativa (2). Eso indica simplificación selectiva con uso cloud-native continuado, no la anterior afirmación de que un 42 por ciento consolidaba o de que service mesh cayó del 18 al 8 por ciento. Prime Video comunicó un 90 por ciento menos de coste de infraestructura para una sola carga de monitorización tras consolidarla en un monolito. Werner Vogels recalcó que no hay una arquitectura universal y que construir sistemas evolutivos es una estrategia, no una religión (3).

Lo que se perdió: ingeniería de sistemas

La ingeniería de sistemas es la disciplina más antigua que desplazó la fragmentación. Trata el sistema en su conjunto, no una colección de partes optimizadas de forma independiente, como principal objeto de diseño. Sus instrumentos son requisitos que capturan la intención antes de construir, contratos de interfaz que gobiernan cómo interactúan las partes, modelos arquitectónicos que hacen legible el conjunto y verificación que compara el sistema construido con lo especificado. Son prácticas poco glamurosas, y la cultura de avanzar deprisa de la era de la fragmentación las trató como lastre burocrático que debía abandonarse en nombre de la velocidad. La ironía, conocida por la historia anterior del Agile empresarial, es que eliminar la disciplina no produjo velocidad duradera; produjo sistemas que se volvieron más lentos y frágiles precisamente porque nadie cuidaba el conjunto.

Mantener un modelo preciso de un sistema grande, con componentes, dependencias, contratos y restricciones, puede exigir mucho trabajo y sufrir drift. Eso no demuestra que la ingeniería de sistemas se abandonara ampliamente ni que fuera inasequible. Una hoja de ruta de MBSE de 2026 señala barreras prácticas de adopción, costes de infraestructura y evidencia limitada de soluciones plenamente automatizadas y escalables en grandes entornos de modelado (4).

Por qué la IA recupera la disciplina

La entrega anterior de esta serie sostuvo que la IA desplaza parte del trabajo de ingeniería de la implementación a la especificación. Los modelos pueden ayudar a mapear código, resumir, mantener trazabilidad y comprobar coherencia, pero no recuperan de forma fiable una intención de negocio no expresada. El artículo MBSE Co-Pilot de 2026 es una hoja de ruta: las herramientas actuales suelen requerir intervención humana sustancial y hasta el nivel de asistencia más alto propuesto conserva la autoridad de diseño humana (4).

Una especificación viva, versionada y reconciliada con el sistema en ejecución es, por tanto, un objetivo de diseño, no un resultado automático de adoptar IA. Los agentes pueden proponer interfaces, señalar posible drift y actualizar borradores, mientras ingenieros responsables validan requisitos, contexto y consecuencias de seguridad. La reducción del coste total depende de la calidad del modelo, tooling, revisión y práctica organizativa.

El límite de la IA por sí sola: confiado no significa demostrado

Pero la ingeniería de sistemas recuperada por la IA reintroduce por sí sola, de forma más sutil, el problema que resuelve. Una especificación reconciliada por un agente sigue siendo un documento; un contrato de interfaz aplicado por un pipeline sigue siendo aplicado por quien controla el pipeline; un registro de auditoría escrito por el sistema solo es tan fiable como la parte que puede reescribirlo. Todo el aparato descansa sobre confianza delegada: el usuario confía en que la organización que despliega haya especificado correctamente, verificado con honestidad y no manipulado el registro. Dentro de una sola empresa puede ser aceptable. A través de las fronteras que definen los sistemas modernos, entre empresas, entre una institución y su regulador, entre una red y sus participantes, es precisamente la suposición que no se sostiene. Y en la era agéntica aumenta lo que está en juego: cuando el código e incluso los cambios arquitectónicos se generan más deprisa de lo que cualquier humano puede revisar de forma independiente, «confíe en nosotros, el sistema hace lo que dice la especificación» se convierte en una afirmación que ninguna contraparte debería aceptar por fe.

La garantía institucional y la verificación criptográfica realizan afirmaciones diferentes. Contratos, auditorías y gobernanza aportan responsabilidad alrededor de una organización y sus controles. Una prueba criptográfica permite comprobar una afirmación codificada sin depender solo de la palabra del operador, pero su alcance se limita a esa afirmación y sus supuestos. La ingeniería de sistemas puede hacer explícita una arquitectura; ni una especificación ni una prueba de cómputo vuelven «cierta» la arquitectura completa.

Cómo la endurece la descentralización

La verificación criptográfica puede hacer comprobable una computación codificada con precisión. Si una afirmación vincula el programa o modelo previsto con inputs comprometidos, un recibo puede demostrar que esa computación produjo el output afirmado (5). Zero knowledge puede ocultar un testigo privado si el sistema y la afirmación se diseñan para ello. No demuestra que los inputs sean ciertos, que el modelo sea apropiado o justo, ni que el proceso cumpla la ley. NIST describe blockchain como un registro resistente y con evidencia de manipulación bajo supuestos de validación, consenso y gobernanza, no como inmutable o carente de confianza sin condiciones (8).

El tooling existe, pero su madurez y alcance varían. RISC Zero documenta recibos para verificar un programa especificado (5). Axiom ofrece hoy una API alojada y solo por invitación para demostrar OpenVM (6). Lagrange ha publicado DeepProve como código abierto y afirma pruebas completas de inferencia LLM; sus datos de rendimiento y volumen son del proveedor y específicos del benchmark (7). Ninguno demuestra una arquitectura empresarial completa. En una decisión de crédito, identidad, calidad de datos, gobernanza del modelo y legalidad quedarían fuera de la prueba de cómputo.

La distribución puede reducir algunos puntos únicos de fallo o control, pero no los elimina automáticamente. El resultado depende de independencia de nodos, consenso, gobernanza, claves, autoridad de actualización y fuentes externas. La gobernanza descentralizada puede hacer visibles las reglas y aun concentrar control efectivo en tenedores de tokens, operadores, firmantes multisig o administradores. La arquitectura debe decir qué garantía está descentralizada y qué sigue siendo confiado.

Las objeciones: madurez y si realmente hace falta

Generar pruebas añade coste computacional y operativo, pero el overhead varía por carga, sistema, hardware y objetivo de seguridad. La anterior afirmación general de que demostrar modelos grandes era miles de veces más lento y solo parcial ya no es un resumen sólido. Lagrange afirma una construcción abierta y completa para inferencia LLM (7). Eso no demuestra economía de producción para cualquier modelo ni entrenamiento, y no vuelve comparables los benchmarks de proveedores.

Los casos de alto riesgo y menor volumen son una prioridad plausible cuando verificar vale más que su coste. No son una secuencia de adopción medida ni inevitable. Decisiones reguladas, liquidación financiera y procedencia de contenidos tienen requisitos diferentes de latencia, privacidad, derecho y modelo de amenazas. Cada equipo debe evaluar la afirmación, quién la verifica, los recursos y los fallos que quedan fuera de la prueba.

Informes SOC 2, entornos de ejecución confiable y pruebas criptográficas responden a preguntas distintas. Una prueba puede demostrar computación codificada, no controles de gobernanza, recogida lícita de inputs, idoneidad del modelo ni compliance completo. Una auditoría tampoco reproduce cada computación. La garantía institucional sigue siendo necesaria; la evidencia criptográfica solo la complementa con un modelo de amenazas y verificador concretos.

Conclusión: diseñado para ser demostrado

La asistencia de IA puede reducir esfuerzo de mapeo, mantenimiento de especificaciones y detección de incoherencias, mientras ingenieros responsables conservan la autoridad de diseño. Los sistemas criptográficos pueden adjuntar evidencia comprobable a computaciones y registros seleccionados. No hacen demostrable una arquitectura completa ni sustituyen la evaluación de inputs, gobernanza, dependencias y compliance.

Ambos enfoques describen una dirección de diseño, no un futuro decidido. La ingeniería de sistemas aporta contexto para elegir qué invariante merece prueba; la verificación aporta evidencia solo para la afirmación codificada. En finanzas reguladas on-chain existen herramientas y pilotos, mientras el encaje jurídico, los controles operativos y la economía de producción dependen de cada implementación.

La pregunta de diseño duradera no es solo la rapidez con que cambia un sistema, sino qué afirmación importante debe poder verificar otra parte. Las organizaciones sólidas la formulan con precisión, identifican la confianza residual y eligen evidencia proporcional al riesgo.

Acerca de Polity

Este artículo forma parte de un programa continuo de publicaciones sobre gobernanza dentro del modelo de Polity. Su tesis central es que los resultados duraderos dependen de reglas, incentivos e instituciones. La ingeniería de sistemas asistida por IA junto con evidencia para computaciones concretas es un problema de gobernanza en este sentido: cada prueba tiene alcance, verificador y supuestos de confianza residuales. Polity construye infraestructura para finanzas digitales reguladas con frameworks destinados a conectar sistemas descentralizados y requisitos institucionales de compliance.

Acerca de Wavect

Wavect GmbH es una agencia austriaca de ingeniería de software que crea software orientado al producto para startups, scale-ups y empresas. Su trabajo abarca desarrollo full-stack, liderazgo fraccional de ingeniería y producto, software quality assurance y trabajo aplicado en inteligencia artificial, blockchain y sistemas zero-knowledge. Wavect ha prestado servicios de desarrollo de software y quality assurance al programa Polity, y el coautor Kevin Riedl es Managing Partner de la firma. Más información en https://wavect.io.

Descargo de responsabilidad: Este artículo se publica exclusivamente con fines informativos y educativos. No constituye asesoramiento profesional, jurídico, financiero o de ingeniería, ni respalda metodología, producto, protocolo, servicio u organización alguna. Las referencias a investigadores, estudios, herramientas, estándares y empresas se incluyen únicamente para análisis y comentario. Varias de las tecnologías analizadas, en especial la computación verificable y las pruebas zero-knowledge de ejecución de modelos, se encuentran en una fase temprana de madurez y sus capacidades y costes evolucionan; el texto caracteriza sus limitaciones relevantes. Todas las fuentes de terceros se citan como referencia; su inclusión no implica respaldo ni afiliación por parte de Polity. El coautor Kevin Riedl es Managing Partner de Wavect GmbH, que presta servicios de desarrollo de software y quality assurance al programa Polity (véase «Acerca de Wavect»); esta relación comercial se declara por transparencia y no afecta a la independencia del análisis. Las opiniones expresadas son propias de los autores.

Referencias y notas de verificación

Revisado por completo el 2 de septiembre de 2026. Las afirmaciones de proveedores sobre rendimiento y adopción se tratan como tales.

1. vFunction (2026), Distributed Monolith Architecture: What It Is, Why It Happens, and How to Fix It. Practitioner definition of the distributed-monolith failure mode. vfunction.com (Accessed: 2 September 2026).
2. Cloud Native Computing Foundation (2025), CNCF Research Reveals How Cloud Native Technology is Reshaping Global Business and Innovation. Official 2024 survey summary: 89% cloud-native adoption and service-mesh adoption moving from 50% in 2023 to 42% in 2024. cncf.io (Accessed: 2 September 2026).
3. Vogels, W. (2023), Monoliths are not dinosaurs. Official discussion of the Prime Video monitoring-workload case, including the reported 90% infrastructure-cost reduction and the linked archived team post. allthingsdistributed.com (Accessed: 2 September 2026).
4. Zhang, W., Cockburn, C., Henshaw, M. et al. (2026), ‘MBSE Co-Pilot: A Research Roadmap’, Systems Engineering, 29(1), 20–33. Current limitations, human oversight and the proposed assistance levels. doi.org/10.1002/sys.70011 (Accessed: 2 September 2026).
5. RISC Zero, Developer Documentation. Receipts certify that a specific program produced a specific output without revealing private inputs when the proof is configured accordingly. dev.risczero.com (Accessed: 2 September 2026).
6. Axiom, OpenVM Proving API Documentation. The current hosted proving API is invite-only. docs.axiom.xyz (Accessed: 2 September 2026).
7. Lagrange (2026), Inside DeepProve: Proving an LLM End-to-End. Official engineering update and vendor-reported end-to-end LLM-inference proof results. lagrange.dev (Accessed: 2 September 2026).
8. NIST (2018, current resource), Blockchain Technology Overview, NISTIR 8202. Blockchain as a shared, tamper-evident and tamper-resistant ledger whose guarantees depend on validation and consensus. csrc.nist.gov (Accessed: 2 September 2026).