BSS/OSS listos para agentes: lo que necesitan los operadores antes de que la IA ejecute operaciones

En un operador grande, un asistente de IA resolvió en unos cuatro segundos una disputa de facturación de un cliente empresa: aplicar una nota de crédito, corregir el plan tarificado, reemitir la factura. Después una persona tardó dos días en ejecutarlo. La nota de crédito requería una aprobación que el sistema no sabía registrar, el cambio de plan había que volver a cargarlo en un segundo catálogo, y la factura no podía revertirse sin un ticket manual. El modelo no era la restricción. Lo era el entorno operativo.

Esa distancia entre decidir y ejecutar es hacia donde se mueve hoy la transformación BSS/OSS. En agosto de 2026 Liberty Latin America firmó un acuerdo a diez años por el cual Amdocs gestionará y transformará todo su ecosistema de IT, operado a través de un sistema operativo agéntico, con el objetivo declarado de pasar de operaciones de IT tradicionales a un modelo impulsado por IA. En el mismo trimestre, Amdocs informó un acuerdo plurianual de servicios administrados con un proveedor sudamericano líder, sobre un stack OSS completo con gestión aplicativa impulsada por IA. No es realmente una historia de proveedores. Ambas señales apuntan al mismo movimiento: los operadores grandes dejaron de comprar funcionalidades de IA y empezaron a comprar un modelo operativo.

La pregunta ya no es si la IA puede asistir a los equipos de telecom. Es si las operaciones de telecom están listas para que agentes actúen de forma segura sobre sistemas que no les pertenecen.

Por qué las operaciones de telecom se resisten a la automatización

Un pedido de un cliente rara vez se queda dentro de un solo sistema. Tomemos un abonado residencial que pasa de un plan de banda ancha de 300 Mbps a un paquete convergente con una línea móvil. La solicitud atraviesa el CRM y la identidad del cliente, el catálogo de productos y las reglas de pricing, la gestión de órdenes, la facturación y el charging en línea, el aprovisionamiento, el inventario de red y de servicio, assurance, al menos un sistema de partner para la pata móvil o el financiamiento del equipo, las notificaciones y, en varios mercados, un registro regulatorio.

Cada uno de esos sistemas tiene su propio modelo de estados y su propia idea de qué significa "activo". También fallan de maneras distintas. Automatizar un paso aislado es sencillo, y la mayoría de los operadores ya lo hizo. La cadena es lo difícil, porque no tiene un dueño único. Cuando los sistemas están débilmente acoplados, una capa de IA puede proponer la acción correcta y aun así no poder completarla. Lo que parece un límite de la IA suele ser un límite de integración.

Del copiloto al agente: la ejecución cambia el modelo de riesgo

Tres cosas muy distintas se nombran hoy con la misma palabra, y no exponen al mismo riesgo.

Un copiloto recomienda; una persona ejecuta y absorbe el error. Un workflow automatiza un camino predefinido con un árbol de decisión fijo, y su comportamiento se conoce antes de correrlo. Un agente elige el camino en tiempo de ejecución, dentro de un alcance que alguien tuvo que definir.

En el momento en que la ejecución pasa de la persona al agente, el costo de una decisión equivocada cambia de escala. Un copiloto que lee mal una tarifa le hace perder un minuto a un asesor. Un agente con permisos de escritura que interpreta mal una regla de suspensión masiva puede dejar decenas de miles de líneas en el estado equivocado antes de que alguien lo note, y en prepago el que lo nota primero es el cliente.

La IA agéntica acorta los ciclos operativos. También acorta la distancia entre una mala decisión y sus consecuencias. De ahí que la agenda práctica sea poco vistosa: permisos, conjunto de acciones permitidas, umbrales de aprobación, pistas de auditoría, procedimientos de reversión, observabilidad, manejo de excepciones y un radio de impacto definido por tipo de acción.

Madurez de las API: los agentes llaman capacidades de negocio, no bases de datos

La decisión de arquitectura que más pesa es qué puede tocar un agente. Un agente nunca debe escribir directamente sobre una tabla de facturación, una ficha de abonado o un objeto de inventario de red. Debe invocar capacidades de negocio gobernadas: crear orden, cambiar plan, suspender servicio, aplicar crédito, disparar aprovisionamiento, abrir un caso de assurance, solicitar un reporte de liquidación.

La diferencia está en todo lo que la capacidad arrastra y la escritura cruda ignora. "Aplicar crédito" valida elegibilidad y el límite de política, registra quién autorizó, notifica al cliente y genera el asiento contable. Un UPDATE directo en base no hace nada de eso y deja una diferencia que alguien concilia a fin de mes.

Las API pensadas para agentes exigen más disciplina que las pensadas para un portal. El agente necesita un catálogo para saber qué existe, y control de acceso por rol para que su alcance se imponga fuera del prompt y no dentro. Los contratos necesitan versionado, porque un agente que aprendió una firma va a seguir llamándola. Las claves de idempotencia importan más que de costumbre: un reintento tras un timeout del gateway no puede emitir dos veces el mismo crédito de 50 EUR. Después vienen la validación y los chequeos de política en el borde de la capacidad, el logging estructurado atado a un identificador de correlación, y los límites de tasa. Un agente atrapado en un loop repite un error más rápido de lo que jamás lo hizo un operador humano.

Consistencia de datos: una verdad operativa compartida

La automatización amplifica lo que los datos ya dicen. La mayoría de los operadores convive con inconsistencias conocidas que los equipos aprendieron a esquivar en silencio: el CRM muestra un servicio activo mientras el aprovisionamiento sigue pendiente; facturación cobra una tarifa y el autoservicio muestra otra; el inventario no refleja el recurso de acceso que realmente se está usando; un sistema de partner nunca confirmó la activación; assurance ve una falla sobre una orden que la gestión de órdenes ya cerró.

Un asesor con experiencia reconoce estos artefactos y llama al equipo correcto. Un agente los toma al pie de la letra. Ante un registro de aprovisionamiento pendiente sobre un servicio que el cliente está usando, puede reabrir una orden ya cumplida, reintentar la activación y generar un segundo cargo. Técnicamente no falló nada. Cada sistema hizo lo que le pidieron.

La condición previa es una verdad operativa compartida. Datos maestros con dueño definido por atributo, un modelo de producto canónico al que resuelvan tanto el catálogo como la facturación, un inventario de servicios que coincida con lo que está efectivamente conectado. Alrededor de eso: flujos de eventos que publiquen cambios de estado en lugar de obligar a los sistemas a consultarse entre sí, conciliación con calendario propio y no recién a fin de mes, y una vista única del estado de un cliente en todos los dominios a la vez.

Orquestación entre dominios, no una capa de IA por encima

Un BSS/OSS listo para agentes son tres capas con responsabilidades claras: la capa de IA y agentes decide, la capa de orquestación ejecuta y controla, y los sistemas BSS, OSS y de partners siguen siendo los sistemas de registro.

Dentro de un loop gobernado, el agente entiende el contexto, elige una acción permitida, llama a la capacidad de negocio correcta, verifica el resultado, escribe la pista de auditoría y deriva la excepción a una persona con suficiente contexto para actuar. La orquestación se queda con lo que los agentes hacen mal: el secuenciamiento entre dominios, los timeouts y la compensación. Si el aprovisionamiento falla después de que el charging ya aplicó, algo tiene que revertir el cargo, restaurar el plan anterior y cerrar la orden con el código de motivo correcto. Eso es diseño transaccional, no un prompt mejor.

Human-in-the-loop: dónde debe detenerse la autonomía

Algunas acciones no deberían ser nunca totalmente autónomas, por bueno que sea el modelo. Cambios tarifarios masivos, créditos y reintegros por encima de un umbral, suspensión de una cuenta empresa o wholesale, cambios en condiciones de liquidación con partners, acciones de red durante un incidente y todo lo que tenga consecuencia regulatoria o impositiva.

El patrón que funciona es la autonomía graduada. Por debajo de 20 EUR el crédito se ejecuta solo; entre 20 y 200 EUR pasa por un supervisor; por encima, por finanzas. Un tope acumulado limita cuánto puede emitir una población de agentes en una hora, de modo que un error sistemático queda contenido en vez de aparecer en el reporte mensual. En la práctica, esos umbrales se escriben después del primer incidente. Escribirlos antes sale bastante más barato. Listo para agentes no significa totalmente autónomo. Significa que cada acción tiene el nivel adecuado de autonomía, aprobación y control.

Por qué los operadores multipaís lo necesitan primero

Los grupos con operaciones en varios países chocan con esto antes. Stacks legacy distintos por OpCo, catálogos distintos, reguladores y reglas de defensa del consumidor distintos, monedas y tratamientos impositivos distintos, ecosistemas de partners distintos, y variantes locales de proceso que existen por buenas razones.

En ese escenario, el valor de una capa lista para agentes no es la unificación. Es poder escalar una práctica gobernada sin reconstruir cada sistema local. Un contrato de capacidad "suspender servicio" se define una vez a nivel grupo y se mapea contra siete implementaciones distintas por debajo, con los mismos permisos, el mismo formato de auditoría y los mismos umbrales de aprobación. La capa de mapeo absorbe las diferencias con las que el agente no debería tener que lidiar.

Qué modernizar antes de desplegar agentes

Las condiciones que separan un piloto de un modelo operativo:

• capacidades BSS/OSS expuestas como API gobernadas, no como pantallas ni acceso a base
• un catálogo de productos unificado, o una capa explícita de mapeo entre catálogos
• datos de cliente, producto y servicio consistentes, con propiedad definida
• integración por eventos entre dominios, no solo conciliación por lotes
• un motor de orquestación que maneje secuenciamiento, reintentos y compensación
• permisos por rol para identidades de máquina, no solo para personas
• logs de auditoría inmutables que registren intención, actor, aprobación y resultado
• procedimientos de reversión y compensación probados, por tipo de acción
• flujos de excepción que deriven a una persona con todo el contexto
• observabilidad sobre el recorrido del cliente, no sistema por sistema
• estándares de integración para interfaces de partners y wholesale

Nada de esto es exótico. Es trabajo corriente de transformación BSS/OSS, que es exactamente por lo que se posterga a favor del piloto de IA, y por lo que después el piloto se frena justo cuando tiene que escribir en algún lado.

Estar listo para la IA es estar listo para la integración

Los operadores que ganen en operaciones impulsadas por IA no serán necesariamente los que tengan el modelo más avanzado. Serán aquellos cuyo entorno BSS y OSS permita una ejecución segura, gobernada y entre dominios, donde cada acción automatizada esté permitida, registrada, sea reversible y observable.

Es una decisión de arquitectura, y se está tomando ahora, en acuerdos a diez años. En Avante vemos el mismo orden de operaciones en todo programa serio: primero la capa de integración, después los agentes.