La parte de la transformación digital que ninguna herramienta incluye
Alrededor de cinco millones de veces al año, alguien llama a KPN, el mayor proveedor de telecomunicaciones de los Países Bajos.
No llama para ponerse al día con un amigo.
Llama porque internet dejó de funcionar justo antes de una reunión, porque un pedido nunca llegó, porque necesita reprogramar la visita de un técnico o porque una mudanza convirtió un servicio casi invisible en un problema urgente.
Para KPN, cada llamada forma parte de una operación enorme.
Para la persona al otro lado, suele ser una interrupción en su vida.
La empresa está desarrollando agentes de IA capaces de mantener conversaciones de voz, acceder a sistemas internos y ejecutar acciones. Su objetivo es que estos agentes atiendan entre el 10 % y el 20 % de las llamadas de servicio al cliente para 2027, sin dejar de ofrecer un camino sencillo hacia una persona cuando sea necesario.[1]
Contada rápidamente, parece otra historia sobre una gran empresa que adopta inteligencia artificial:
Había demasiadas llamadas.
Apareció una tecnología capaz de atenderlas.
La empresa decidió usarla.
Todo encaja.
Suena al guion de siempre: otra organización que sigue la tendencia porque no puede permitirse quedarse atrás.
Pero KPN no comenzó por ahí.
Antes de que un agente dijera «hola», tuvo que ocurrir algo menos llamativo y mucho más importante:
Escuchar, clasificar y decidir.
KPN no comenzó eligiendo un modelo.
Comenzó escuchando.
El caso KPN, en cuatro números
Escuchar antes de automatizar
El equipo utilizó un sistema basado en modelos de lenguaje para analizar grandes volúmenes de transcripciones de llamadas y conversaciones por chat.
Los datos habían sido anonimizados. El objetivo inicial no era automatizar, sino comprender.
¿Por qué llamaban las personas?
¿Con qué frecuencia aparecía cada necesidad?
¿Qué procesos se escondían detrás de esas conversaciones?
¿Debían automatizarse esos procesos, simplificarse o quizás rediseñarse para que los clientes ya no necesitaran llamar?
Los equipos técnicos y de experiencia del cliente evaluaron después cada oportunidad según su impacto potencial, costo, complejidad, viabilidad y la necesidad de mantener a una persona involucrada en el proceso.
Ese análisis dio lugar a los primeros casos de uso: verificación de identidad, consultas sobre pedidos, gestión de citas con técnicos y diagnóstico inicial de problemas de conexión.[1]
La IA fue útil desde el principio.
Podía revisar más conversaciones de las que cualquier equipo humano sería capaz de leer. Podía agrupar temas, contabilizar problemas recurrentes e identificar patrones dispersos entre millones de palabras.
Pero frecuencia no es lo mismo que valor.
Que una pregunta aparezca miles de veces todavía no nos dice si debemos responderla con un agente, cambiar el proceso que la provoca o eliminar por completo la necesidad de que el cliente tenga que hacerla.
Eso exige otro tipo de trabajo.
Fred Brooks escribió en 1986:
«La parte más difícil de construir un sistema de software es decidir con precisión qué construir». —Fred Brooks.[2]
Brooks no estaba restando importancia al código. Estaba separando dos tipos de dificultad que solemos confundir.
Una consiste en expresar una solución: escribirla, probarla, desplegarla y mantenerla.
La otra consiste en comprender el problema lo suficiente para saber qué solución debería existir.
La IA está reduciendo rápidamente el costo de la primera. Puede generar código, explorar repositorios, comparar alternativas y producir prototipos en minutos.
La segunda permanece.
En KPN, el modelo ayudó a la organización a comprender. Las decisiones sobre qué priorizar siguieron siendo humanas.
La IA podía encontrar patrones.
El criterio todavía tenía que decidir cuáles importaban.
Como ingeniero de software, he aprendido que mi mayor ventaja en los equipos donde he trabajado rara vez ha sido ser el mejor programador. He conocido programadores mejores que yo.
Tampoco ha sido ser la persona más elocuente de la sala ni quien conoce más tecnologías.
Mi pequeño truco ha sido otro:
Intentar entender el negocio.
Cuando entiendes el negocio, entiendes dónde está el verdadero dolor. Sabes qué problema existe detrás de una funcionalidad, dónde vale la pena invertir tiempo y qué merece realmente prioridad.
Quizás por eso el caso de KPN me resultó tan familiar.
Trabajo en tecnología de sistemas. Escribo software, diseño arquitecturas, conecto servicios y automatizo procesos. Son las herramientas que mejor conozco para intervenir en la realidad.
Pero no me considero ingeniero simplemente porque sé utilizarlas.
Me considero ingeniero cuando puedo entrar en un problema que todavía no está claro, separar los síntomas de las causas y encontrar un camino razonable desde el estado actual hacia uno mejor.
A veces ese camino termina en software.
A veces no.
Hoy, a medida que la IA elimina parte de la fricción técnica, entender el negocio y tomar decisiones críticas importa más, no menos.
La mudanza que no cabía en un flujo de trabajo
Entre las situaciones que KPN analizó, hubo una especialmente reveladora:
Una mudanza.
Desde una perspectiva técnica, cambiar la dirección asociada a un servicio parece el candidato perfecto para la automatización.
Hay una dirección anterior, una nueva, una fecha y un conjunto de productos que deben transferirse.
Es fácil imaginar el diagrama: cuatro cajas, algunas reglas y varias flechas.
Pero mudarse no es solo una tarea administrativa.
Es uno de esos momentos en los que todo queda abierto a reconsideración: gastos, contratos, proveedores.
Cuando alguien ya está cambiando de casa, cambiar de proveedor de telecomunicaciones puede parecer una decisión adicional relativamente menor.
El cliente puede estar más dispuesto a reconsiderar su relación con la empresa justo en el momento en que el proceso parece más sencillo de automatizar.
Por eso KPN no evaluó únicamente si un agente podía completar la operación. También consideró qué momentos debían conservar la intervención humana, sobre todo cuando el riesgo de perder al cliente era mayor.[1]
Peter Drucker dejó una advertencia especialmente útil para casos como este:
«No hay nada tan inútil como hacer con eficiencia algo que no debería hacerse en absoluto». —Peter Drucker.[3]
La inteligencia artificial añade una variante inquietante a esa idea.
Ahora podemos hacer lo incorrecto más rápido, a menor costo y con autonomía suficiente para repetirlo miles de veces.
Un mal proceso ejecutado manualmente genera fricción.
Un mal proceso automatizado puede convertirse en infraestructura.
Puede reducir tiempos de procesamiento, aumentar el volumen y producir métricas aparentemente saludables. La máquina funciona. Los tableros están en verde.
Y, aun así, podemos estar haciendo con admirable eficiencia algo que nunca debió conservarse de esa manera.
KPN no rechazó automatizar las mudanzas.
Hizo una pregunta más cuidadosa.
La pregunta difícil no era si un agente podía gestionar la mudanza.
Era qué se perdería si el agente la gestionaba solo.
Dos segundos
Una vez seleccionados los problemas, comenzó la parte que reconocemos con más facilidad como tecnología.
KPN necesitaba que sus agentes de voz respondieran en menos de dos segundos.
En un tablero de rendimiento, dos segundos parecen insignificantes.
Durante una llamada telefónica, pueden bastar para que alguien piense que se cortó la comunicación, repita la pregunta o diga «¿hola?» mientras espera una respuesta.
La voz no tiene un indicador de carga que explique el silencio.
La latencia deja de ser una métrica de infraestructura.
Se convierte en parte de la experiencia.
El equipo también trabajó en el barge-in: la capacidad de permitir que una persona interrumpa al agente mientras habla sin que el sistema pierda el contexto.
Es un detalle fácil de subestimar.
Las conversaciones humanas no respetan turnos perfectos. Interrumpimos, dudamos, nos corregimos y cambiamos de dirección a mitad de una frase.
Un sistema incapaz de tolerar esa imperfección puede tener una voz impecable y aun así sentirse profundamente artificial.[1]
Esos requisitos guiaron la arquitectura.
KPN evaluó distintas alternativas y eligió una plataforma conversacional integrada y administrada. La decisión redujo la complejidad de integración, ofreció una latencia más predecible y permitió que la empresa avanzara con rapidez, aunque también introdujo cierto grado de dependencia del proveedor.[1]
No eligieron la solución más flexible en términos absolutos.
Eligieron la que mejor respondía al problema que tenían delante.
Hay algo importante en ese orden.
Primero decidieron cómo debía sentirse la conversación.
Después eligieron la tecnología capaz de producir esa experiencia.
A veces lo que llamamos un «requisito técnico» es en realidad comportamiento humano traducido a un número.
La arquitectura no creó el criterio.
Lo hizo visible.
Cuando la voz recibió permisos
KPN no intentaba construir un chatbot que se limitara a explicar cómo un cliente podía completar una operación.
Quería agentes capaces de completarla.
Un chatbot puede decir:
«Puedes cambiar tu cita visitando esta sección».
Un agente puede consultar la disponibilidad, reprogramar la cita y confirmar la nueva fecha.
La diferencia se describe en pocas palabras.
En términos operativos, es enorme.
Para hacerlo posible, los agentes se conectaron a los sistemas centrales mediante API estandarizadas y MCP, un protocolo que proporciona acceso estructurado a herramientas y datos. La arquitectura incluía capas para la plataforma de agentes, la orquestación y la integración de audio, y fue diseñada para reutilizar sus componentes en nuevos casos de uso.[1]
En el momento en que un modelo recibe permisos, deja de ser únicamente un generador de lenguaje.
Pasa a formar parte de la operación.
Una respuesta incorrecta puede confundir a alguien.
Una acción incorrecta puede modificar una cita, acceder a información inadecuada o dejar un proceso en un estado inconsistente.
Cuando el lenguaje recibe permisos, sus errores dejan de ser solo palabras.
Por eso KPN introdujo límites sobre lo que los agentes podían decir y hacer, junto con herramientas de observabilidad, registros de extremo a extremo y sistemas de evaluación que combinaban revisiones humanas con comprobaciones automatizadas.
No bastaba con saber si la respuesta sonaba convincente.
La organización también necesitaba saber a qué información había accedido el agente, qué acción había ejecutado, si había respetado sus límites y si el problema del cliente realmente se había resuelto.
La cautela no era excesiva. KPN estaba construyendo agentes destinados a interactuar con más de 100 000 clientes por semana. A esa escala, un error poco frecuente deja de ser una pequeña excepción.[1]
El criterio no vive dentro del modelo.
Pero puede expresarse mediante la arquitectura que lo rodea.
Vive en los permisos que nos negamos a conceder.
En las acciones que requieren confirmación.
En la información a la que el agente no puede acceder.
Y en el momento en que debe dejar de improvisar y transferir la llamada a una persona.
Cien llamadas cada mañana
KPN llevó versiones mínimas viables a producción, realizó pruebas con equipos multidisciplinarios e involucró a clientes reales mediante un laboratorio de experiencia de usuario.
Después inició un ciclo que, para mí, contiene una de las lecciones más importantes de todo el caso.
Cada mañana, el equipo revisaba las transcripciones de hasta cien llamadas reales.
Allí encontraba expresiones inesperadas, ambigüedades y situaciones que nadie había imaginado durante el proceso de diseño.
Para la tarde, esos descubrimientos ya se habían convertido en ajustes a los prompts.
Los cambios podían estar activos ese mismo día.[1]
Es tentador atribuir esa velocidad a la inteligencia artificial.
El modelo abarató los cambios en el comportamiento del sistema. Pero no creó por sí solo el ciclo de aprendizaje.
No decidió revisar las llamadas.
No reunió a personas de tecnología, negocio y experiencia del cliente.
No les dio autoridad para cambiar el sistema.
Tampoco creó una cultura capaz de admitir que una hipótesis había sido incorrecta.
La organización hizo todo eso.
La agilidad no es simplemente la capacidad de producir más rápido.
Es la capacidad de reducir la distancia entre observar la realidad, aprender algo de ella y convertir esa lección en un cambio.
Una empresa puede utilizar el modelo más avanzado del mercado y aun así tardar tres meses en aprobar una corrección.
Otra puede trabajar con tecnología menos sofisticada y mejorar cada día porque sabe escuchar y decidir.
La IA redujo el costo de hacer correcciones.
KPN redujo el tiempo entre escuchar y actuar.
La agilidad de KPN no estaba dentro del modelo.
Estaba en la distancia que la organización logró eliminar entre escuchar y corregir.
Las personas que faltan en el diagrama
Hay una forma habitual de representar la transformación digital.
Los datos entran por un lado.
Un modelo los procesa.
Una acción sale por el otro.
En el centro hay cajas, flechas y API.
Las personas suelen quedar fuera del diagrama.
Pero los procedimientos, las responsabilidades, la formación y los temores de quienes trabajan dentro de la organización también forman parte del sistema.
KPN creó un equipo dedicado a actualizar los procedimientos operativos, desarrollar programas de formación y acompañar la evolución de los roles de sus empleados. También involucró al personal de primera línea en el desarrollo y las pruebas.
La empresa reporta una tasa de éxito superior al 86 % en su estrategia de adopción. A medida que los agentes asumen tareas rutinarias, los especialistas humanos pueden concentrarse en situaciones donde el criterio y la empatía son más importantes.[1]
La IA no libera automáticamente a las personas para que realicen un trabajo de mayor valor.
Para que eso ocurra, alguien tiene que rediseñar el trabajo.
Los procedimientos, las rutas de escalamiento, las responsabilidades y las métricas deben cambiar. Las personas que reciben los problemas que el agente no pudo resolver tienen que estar preparadas para ellos.
De lo contrario, la tecnología no elimina una capa de complejidad.
Añade otra.
Quizás el activo más importante que KPN está construyendo no sea ninguno de sus agentes actuales.
Es la capacidad interna de descubrir oportunidades, elegirlas con cuidado, construir soluciones, observarlas en producción y corregirlas sin comenzar desde cero cada vez.
Los modelos cambiarán.
Las plataformas cambiarán.
Muchos de los agentes actuales serán reemplazados.
Pero una organización que aprende a escuchar, decidir y corregir conserva algo valioso incluso cuando todas sus herramientas son sustituidas.
Eso se parece mucho más a una transformación digital.
No porque la empresa tenga IA.
Sino porque está aprendiendo a resolver problemas de otra manera.
Una interpretación necesaria
La parte que todavía nos corresponde
Seguiré utilizando inteligencia artificial.
Probablemente la utilizaré cada vez más.
Me ayuda a investigar, explorar alternativas, escribir código y enfrentar problemas que antes habrían requerido mucho más tiempo.
Ignorar una herramienta con ese poder sería absurdo.
Pero confundir la velocidad que me proporciona con el criterio que se espera que yo aporte sería peligroso.
Mi campo es la tecnología de sistemas. Es el conjunto de herramientas que mejor conozco para intervenir en la realidad.
Pero no me considero ingeniero porque cada problema que toco termine convirtiéndose en software.
Me considero ingeniero porque entiendo que puede no hacerlo.
El trabajo comienza antes de la arquitectura, cuando intentamos entender por qué existe el problema, qué fuerzas lo mantienen y qué cambio produciría de verdad un estado mejor.
Continúa mientras elegimos entre alternativas imperfectas.
Y vuelve a comenzar después del despliegue, cuando la realidad revela qué partes de nuestra solución eran correctas y cuáles solo sonaban razonables dentro de una sala de reuniones.
La lección más importante de KPN no es que todas las empresas deban construir agentes de voz.
Es que, antes de construirlos, alguien tuvo que escuchar millones de conversaciones y decidir cuáles importaban.
Después, alguien tuvo que elegir qué no automatizar.
Traducir la experiencia humana en restricciones técnicas.
Aceptar compromisos arquitectónicos.
Rodear el modelo de límites.
Escuchar llamadas reales.
Corregir el sistema con rapidez.
Y preparar a la organización para trabajar de otra manera.
La inteligencia artificial estuvo presente durante todo el recorrido.
Pero no aportó el criterio que le dio dirección al trabajo.
Tampoco aportó la agilidad que transformó los errores en aprendizaje.
Esas no son características de una herramienta.
Al otro lado de cada llamada no hay un «caso de uso».
Hay una persona cuyo día fue interrumpido.
Recordarlo puede ser el primer acto de ingeniería.
Antes del agente, alguien tuvo que escuchar.
Esa parte todavía nos corresponde.
Fuentes y lecturas adicionales
McKinsey & Company y QuantumBlack. How KPN Is Building an Agentic AI Engine for Customer Care. Caso de estudio publicado el 24 de junio de 2026.
Frederick P. Brooks Jr. No Silver Bullet: Essence and Accidents of Software Engineering. Universidad de Carolina del Norte en Chapel Hill, 1986.
Peter F. Drucker. Permanent Cost Cutting. The Wall Street Journal, 11 de enero de 1991; archivado por el Drucker Institute.
