7. Caso: una telco

Pocas industrias ponen a prueba esta tesis como las telecomunicaciones. Un operador factura cada mes a millones de clientes, cobra en tiempo real el consumo de cada línea prepago, responde ante un regulador que audita sus reclamos y sus plazos, y vende un catálogo que cambia más rápido que cualquier ciclo de desarrollo. Su sistema de soporte del negocio, el BSS, es de los más complejos que existen en una empresa. Si el sistema de verdad y las capas de control sirven aquí, sirven en casi cualquier parte.

El operador de este capítulo no existe. Lo construyo con lo que la industria publicó, sobre todo el TM Forum, la asociación que reúne a operadores y proveedores de telecomunicaciones y escribe sus estándares. Dos advertencias sobre esas fuentes. Varios de sus informes están patrocinados por proveedores de software para operadores, y declaro el patrocinio la primera vez que cito cada informe. Y casi todo lo que sigue es lo que los operadores declaran en entrevistas y encuestas, no mediciones de resultados.

¿Dónde está el operador?

En el mismo lugar que muchos, según el informe del TM Forum sobre la inteligencia artificial en la facturación. El informe constata que en muchos operadores persisten paisajes de BSS heredados y fragmentados, y enumera lo que arrastran: costos altos, ineficiencia operativa, restricciones en la experiencia del cliente, poca agilidad del negocio, experiencias rígidas para empleados y clientes, personalizaciones caras, lentas y complejas, y la dificultad de cumplir nuevas exigencias regulatorias y de seguridad sin más personalización.¹ Dicho con la definición del capítulo 1, ese paisaje es el negocio del operador descrito una vez, con capas de personalización encima, y que cambia solo cuando alguien abre un proyecto; da lo mismo si cada pieza se licencia, se arrienda o se hizo a medida. El informe sobre la gestión de órdenes agrega tres problemas clásicos: las órdenes que se caen en el camino, a lo que la industria llama fallout; la dificultad para cambiar una orden ya en curso, y la poca visibilidad que tiene el cliente.²

Con un BSS así, lanzar una oferta nueva toma semanas. Un operador africano que publicó sus resultados, Safaricom, contaba que antes de modernizar su facturación convergente sobre los estándares del TM Forum tardaba cuatro semanas o más en llevar una oferta al mercado, y unos cinco días después.³

¿Qué le pregunta al mercado?

La pregunta de siempre sería qué suite comprar: comparar tres o cuatro parecidas, elegir la que mejor cubre lo que el operador ya hace y firmar por varios años. El riesgo de esa pregunta es comprar, con otro nombre, la misma dependencia.

La pregunta que cabe en 2026 es más amplia: qué le conviene, si comprar una suite o construir su BSS con agentes bajo su control. Para responderla con justicia hay que medir a las dos formas de solución con la misma vara, y eso exige pedir capacidades en lugar de productos: decir qué debe lograr la solución y cómo se verifica, sin presuponer si se compra o se construye.

Los estándares hacen aquí un trabajo enorme. El TM Forum describe la arquitectura de un operador en su Open Digital Architecture, ODA, que presenta como un marco de arquitectura, un lenguaje común y unos principios de diseño, con interfaces abiertas que exponen las capacidades del negocio.⁴ Un operador puede escribir sus requisitos sobre ese mapa, y cualquier oferta responde sobre el mismo mapa.

¿Qué no se construye con agentes?

El núcleo que tasa y factura. El informe del TM Forum sobre facturación recoge que, en la opinión actual de muchos expertos de esa industria, la IA probabilística por sí sola es demasiado arriesgada para una facturación determinista a escala: la IA se basa en probabilidades y la facturación es un proceso determinista, en el que el uso debe tasarse siempre con las tarifas correctas.⁵ El mismo informe dice que la mayoría de los expertos no propone, por ahora, poner la IA en el corazón del motor de facturación, y que su papel ahí, ampliamente aceptado, es asegurar el rendimiento y la exactitud de ese motor.⁶ Un arquitecto jefe de Telstra lo dijo pensando en la red, y la idea se traslada a la facturación: aunque algo pase de una probabilidad de uno en veinte a una de uno en cien de salir mal, eso todavía puede ser una falla.⁷

Ese núcleo pertenece a la primera capa de control. Lo que se tasa, lo que se cobra, lo que se factura, los saldos y sus ajustes viven en el sistema de verdad del operador, y los agentes trabajan alrededor. Lo que sí pueden hacer en la facturación lo describe el mismo informe: verificar datos y detectar anomalías antes y durante la facturación, o revisar las descripciones de los paquetes contra sus tarifas.⁸

En otras palabras: en el corazón de la telco, el núcleo que tasa y factura sobrevive, o al menos sobrevive su promesa de determinismo, y lo que muere es el negocio congelado a su alrededor. Es lo que el capítulo 3 anticipaba: lo que se sigue comprando, cuando ya no se compra el resto, es la verdad.

El informe trae una formulación que podría estar en el capítulo 5. Al describir cómo debería ser una factura por resultados, pide que sea auditable: que los clientes puedan reconstruir los eventos facturables a partir de sus propios datos.⁹ Y un proveedor de facturación, en un artículo patrocinado del mismo informe, pide poder reproducir el cálculo a partir de hechos registrados, y conservar lo que pidió un agente, lo que lo autorizó y lo que cambió.¹⁰ Es la propiedad del origen trazable, y es la condición para que un tercero pueda verificar después.

¿Dónde sí trabajan los agentes?

Donde el proceso no es determinista. Un arquitecto de T Wholesale, de Deutsche Telekom, lo describe para las órdenes con datos inválidos: se puede devolver la orden al cliente o trabajar internamente el manejo de la excepción, y en estos casos lo agéntico se puede usar muy bien.¹¹ Y dice también dónde no: si un proceso es fuertemente determinista, no tiene sentido usar inteligencia artificial. En una demostración del TM Forum con Telstra, los agentes encadenan flujos pequeños definidos de antemano para cumplir la intención de cada cliente en el momento.¹² Es el patrón del capítulo 3.

¿Qué piden los operadores antes de dejar actuar a un agente?

La encuesta del TM Forum y el IBM Institute for Business Value a 130 directivos de operadores de Norteamérica, Europa, Asia y otras regiones, sin Latinoamérica, preguntó qué condiciones pesan más para dejar que la IA opere sin intervención humana. Las más citadas: salvaguardas contra la caída del servicio o el daño al cliente, 51 %; poder detener, pausar o revertir las acciones de la IA, 49 %; pruebas y validación antes del despliegue, 48 %; privacidad y soberanía de los datos, 43 %; una bitácora de todas las acciones de la IA, 43 %; y que las decisiones sean explicables, 32 %.¹³ Varias calzan con las capas de control: la bitácora con la verdad, poder detener y revertir con el movimiento y su reversa, las pruebas previas con la medición. Otras, como la privacidad, quedan fuera del marco de este libro.

El mismo estudio trae el dato que más me impresionó de todo el material. El 72 % de los encuestados confía en poder operar su IA de forma confiable. Solo el 18 % puede producir evidencia que un tercero pueda revisar, y apenas el 14 % tiene las dos cosas.¹⁴ La confianza va por delante de la prueba, en palabras del informe.

Esa brecha está cerca del problema de este libro: la confianza va por delante de la evidencia que un tercero puede revisar. La encuesta mide la evidencia sobre la IA, no la verdad de los registros; creo que las dos brechas tienen el mismo origen, pero la encuesta no lo prueba. El informe llega a una conclusión vecina: las atestaciones periódicas funcionan cuando los sistemas son deterministas y cambian poco; en las operaciones autónomas, los sistemas son probabilísticos y cambian todo el tiempo, y la evidencia tiene que volverse continua.¹⁵ Un proveedor de BSS, en un artículo patrocinado del mismo informe, lo plantea casi con las palabras del capítulo 5: hoy nadie puede entregar a un regulador, a un socio o a un cliente un registro firmado y verificable de forma independiente que pruebe que el agente se mantuvo dentro de sus límites cuando actuó.¹⁶

¿Cómo se ven las capas de control en el operador?

La verdad. El sistema de verdad sostiene el consumo tasado, los saldos, los cargos, las facturas y los pagos; los contratos de abonado, las órdenes y el parque vendido; los registros de uso, los reclamos y sus plazos, la portabilidad y los consentimientos que exige el regulador. Una suite licenciada y operada por el operador cumple esta capa con su núcleo de registros; una arrendada la cumple a medias, porque el núcleo lo opera el proveedor. Una construcción la cumple con tecnología de un proveedor que responde por ella, y en los dos casos hace falta quien atestigüe.

La identidad y la autoridad. Cada agente que toca una orden, un reclamo o un ajuste tiene identidad y permisos propios, y cada acto tiene un área que responde. El 23 % de los operadores encuestados ya tuvo en el último año un incidente de lo que la industria llama «agencia excesiva»: un agente que hizo más de lo que debía.¹⁷

El movimiento. Los agentes trabajan en la atención, en las excepciones de las órdenes y en la conciliación, con autonomía concedida por grados. La autonomía plena es rara: en la facturación y el aseguramiento del ingreso, solo el 4 % de los encuestados declara operaciones totalmente autónomas.¹⁸

La medición. Solo uno de cada cuatro encuestados dice verificar sus controles de forma continua y automatizada.¹⁹

El criterio. ODA, el modelo de información del TM Forum y sus interfaces abiertas son el punto de partida, y sobre ese mapa un componente debería poder cambiarse sin rehacer el resto, aunque esa es la parte menos madura de ODA (capítulo 3).

Y las dos dimensiones: las personas, porque un BSS cuyo comportamiento no entiende nadie del operador repite la dependencia que el operador quería dejar; y la reversa, porque un operador no puede dejar de facturar ni de atender mientras arregla un agente.

¿Y si el operador no sabe desarrollar?

Es la objeción más fuerte que encontré, y viene del propio TM Forum. Su analista jefe escribe que la inmensa mayoría de los operadores tiene capacidades limitadas de desarrollo de software: ensamblan, integran y mantienen lo que compran a sus proveedores, y eso «es improbable que cambie en la era de la IA».²⁰ Las cifras de otro informe lo acompañan: los operadores invierten en promedio el 1,3 % de sus ingresos en investigación y desarrollo, y sus proveedores el 16,7 %, y durante veinte o treinta años le subcontrataron a los proveedores esa función.²¹ Y el estudio de mayo de 2026 observa que, por ahora, parece inevitable que los operadores necesiten más apoyo de sus proveedores para llevar la IA a sus arquitecturas, aunque avisa que todavía no hay un cuadro claro.²²

Pero el Forum no dice lo mismo en todas partes. En la misma página de la primera cita admite que los operadores no han tenido equipos propios de desarrolladores, «pero esto está empezando a cambiar».²³ En su encuesta de diciembre de 2025 y enero de 2026, el 66 % de quienes respondieron considera central la ingeniería de software y solo el 9 % cree improbable que eso cambie, aunque la mitad de los encuestados son ellos mismos arquitectos o ingenieros de software. Los grandes operadores armaron equipos centrales de desarrolladores desde 2015, y Vodafone anunció que contrataría 7.000 en el Reino Unido hasta 2025.²⁴ Los dos hechos caben juntos: que la ingeniería sea central para una empresa no es lo mismo que tener el equipo, y la propia encuesta separa a una cuarta parte que dice que lo será, pero que hoy tiene capacidades limitadas. Esa cola es la que tengo en mente; cuánto pesa en el total de los operadores no está medido. Y esos equipos, mientras cambien el sistema por proyecto, son el desarrollo a medida del capítulo 1: existen hoy, y quedan del lado de lo que muere.

Concedo, para discutirla, la premisa del Forum entera: que la mayoría de los operadores no va a desarrollar software, ni con ayuda de la inteligencia artificial, aunque el propio Forum admite que, en teoría, el low-code y la IA generativa le dan a cualquiera la posibilidad de escribir el suyo, y aunque sus propias cifras, las que acabo de citar, apuntan en otra dirección. Mi tesis no necesita que sea falsa. Lo que niego es la consecuencia: que quien no desarrolla tenga que depender de la aplicación y de la hoja de ruta de quien se la vende.

Una parte del Forum, cuando habla de agentes, imagina que escriben el código más rápido. Su estudio de las tecnologías de información de los operadores llama a la IA agéntica la tercera fase de la función de arquitectura, y dice que va a «aumentar masivamente el volumen de software que un equipo de desarrolladores puede producir». La fábrica digital de Jio, donde los dueños de cada proceso describen lo que quieren y los agentes producen la aplicación, y la configuración por intención que espera Swisscom, se parecen más a lo que yo describo, y en eso el Forum va por delante de mucha gente.²⁵ La diferencia es qué sale del agente, y es la frontera entre las dos lecturas del capítulo 3, la agéntica y la agentiva. Allí sale una aplicación que alguien despliega y mantiene. Aquí sale una memoria del trabajo, y cuando falla, el agente hace el trabajo él mismo mientras la rehace, sin que el operador tenga que arreglar código a las tres de la madrugada.²⁶

En la lectura agentiva, la que describe AgencyDomains, lo que se repite el agente lo cristaliza en Botlets, y los Botlets son suyos: los hace el agente que atiende el trabajo —hoy, configurando una pieza de catálogo—, no otro para que el agente los use. La organización decide qué trabajo tiene que existir y qué es hacerlo bien. Es lo que un ejecutivo de Orange, citado por el propio Forum, llama el juicio, y que él dice de la función de arquitectura: cuando ejecutar se vuelve barato, lo que decide el resultado es quién decide qué construir, cómo y por qué.²⁷ El experto del operador, que sabe cómo se tasa un plan convergente, cómo se resuelve un reclamo de portabilidad o por qué se cae una orden, le enseña ese saber al agente y valida que lo aprendió. No es que no haya proveedor: cada Capability, el saber hacer que el agente aprende del experto, la crea una práctica de entrega que trabaja con él. Lo que cambia es qué entrega: saber, y no aplicaciones.[^wingtraining]

Y el operador aporta su gobierno: quién concede los permisos, quién supervisa, quién define las pruebas, quién responde por cada registro y quién decide qué debe existir. Son las personas de las capas de control del capítulo 6, y en la quinta, el equipo de arquitectura que juzga lo que el agente forma por lo que hace, no por lo que dice su código.

La cifra del 1,3 % mide, entonces, un insumo que deja de ser el escaso. Lo que pasa a ser escaso es el saber del negocio y la capacidad de gobernar a quien hace el trabajo. Lo primero, creo, el operador lo tiene, aunque parte de él vive hoy en las personalizaciones de sus proveedores y es lo primero que habría que recuperar. Lo segundo suele faltarle, y no se compra con una suite. El arquitecto jefe del Forum lo intuye: con sistemas autónomos, dice, el software se gestiona como se gestiona a las personas, mediante delegación, límites, supervisión y rendición de cuentas.²⁸ Y el mismo informe de la primera cita recoge, de sus conversaciones con operadores, que sin una cultura de software o sin estar construyéndola es muy difícil estar a la vanguardia de la IA.²⁹ Yo lo diría de otro modo: sin una cultura de gobierno del trabajo, es muy difícil que los agentes trabajen para el operador y no al revés.

Esto es lo que concedo. Comprar no desaparece: el operador sigue comprando el núcleo de verdad del capítulo 5, el razonamiento de los modelos que usan sus agentes y los componentes que la regulación obliga a certificar, que el agente invoca y no regenera.³⁰ Y hoy la pieza de partida la escribió otro. La implementación de referencia de AgencyDomains opera en su primera etapa, en la que el agente configura piezas de un catálogo que él no escribió, y si ese catálogo es de un proveedor, crea una dependencia.³¹ La diferencia con la suite es que la pieza adoptada el agente la puede sustituir, y creo que sin rehacer el resto, aunque eso tampoco está medido, y que no hay una aplicación entera cuya hoja de ruta sea de otro.

Que el agente forme y mantenga sus piezas sin que nadie las programe no está medido en ninguna telco. Entre diciembre de 2025 y enero de 2026, solo el 5 % de los ejecutivos de TI que respondieron esa pregunta, entre los 216 encuestados de 111 operadores, decía tener agentes integrados en su arquitectura y en producción.³² A esta parte de la tesis la refutaría un operador que corra su BSS con agentes y, pasado un año, tenga que pagarle a alguien, empleado o contratista, para escribir o corregir el código de las piezas a medida, fuera de lo que el catálogo ya ofrece, cada vez que su negocio cambia: si cambiar una pieza exige que una persona programe, la lectura agentiva es la agéntica con otro nombre. La refutaría también un operador que, pasado ese año, solo pueda cambiar su negocio cuando quien mantiene el catálogo publica la pieza que necesita: la dependencia habría pasado de la aplicación al catálogo. Ningún operador está todavía en condiciones de probar ni lo uno ni lo otro.

¿Qué dice la industria en contra?

Bastante, y con fuerza. Amdocs, uno de los mayores proveedores de BSS y patrocinador de dos de los informes citados, ofrece agentes especializados que colaboran en la atención, el comercio, las órdenes y el aseguramiento, con política aplicada en el momento de la ejecución y cada agente como entidad auditable.³³ Varios proveedores de facturación sostienen que los operadores no necesitan transformaciones de alto riesgo de su núcleo y pueden superponer agentes sobre lo que ya tienen.³⁴ Un ejecutivo de Globe Telecom estima que el 90 % de lo que hace falta para confiar en la IA, en ciberseguridad, privacidad y gobierno de datos, ya lo tiene cubierto con las prácticas de siempre.³⁵ El informe advierte que, para quien construye más capacidades de IA propias, el gasto en IA puede parecer mayor que para quien compra soluciones con la IA incorporada, y que en un sistema agéntico el consumo de los modelos puede escalar de forma dramática e impredecible.³⁶ Y el director de informática de KPN recuerda que llevar los agentes de los pilotos a la escala implica cambiar toda la pila de TI de un operador.³⁷

Esto es lo que concedo. Si un proveedor de suites ofrece agentes auditables, gobernados y con el núcleo intacto, puede cumplir las cinco capas de control, y entonces comprar es una respuesta legítima. El argumento de este libro no prueba que construir convenga más que comprar. Prueba otra cosa: que, se compre o se construya, la verdad necesita su contrato y sus dos garantes. Y no sé cuánto cuesta operar con agentes a escala: la escalera del capítulo 3 dice dónde debería bajar ese costo, no cuánto. Nadie lo sabe todavía, y el costo de quien compra queda oculto dentro de la licencia.

Hay evidencia que cambiaría mi tesis, y vale la pena nombrarla. Que el núcleo de verdad se siga comprando no la cambia: es parte de ella. La cambiaría que los operadores que construyen alrededor de ese núcleo con agentes no logren salir al mercado más rápido, ni cambiar sus procesos con menos dependencia, que los que compran suites con agentes. Si eso pasa, el software como lo conocemos habrá sobrevivido mejor de lo que este libro cree. La encuesta del TM Forum no pregunta si los operadores construyen con agentes en lugar de comprar. Pregunta algo vecino: entre los operadores que adoptan su arquitectura abierta, el 36 % dice que ya trae a casa más de su tecnología y el 55 % espera que eso pese poco.³⁸ La medición que importa, la de construir con agentes, sigue faltando.