ELISATECH

El enjambre de agentes: ¿para qué sirve realmente?

2026-10-17T14:04:21.019-07:00

El enjambre de agentes: ¿para qué sirve realmente?

Sistemas multiagente: de la demo al trabajo coordinado

Hace un tiempo, hablar de inteligencia artificial era hablar de modelos que respondían preguntas o redactaban un texto. Hoy la conversación es otra. Los agentes ya no solo responden: ejecutan tareas, usan herramientas, consultan información y le pasan trabajo a otros agentes. Cuando varios de ellos se coordinan, tenemos lo que se conoce como sistema multiagente, o “enjambre de agentes”.

Y con eso cambia la pregunta. Ya no es qué puede hacer un agente, sino qué puede hacer un equipo de agentes y, sobre todo, para qué nos serviría de verdad.

El problema que queremos resolver

Piensa en una consultora pequeña o en un área interna. Hay que investigar temas nuevos, preparar contenido y materiales de capacitación, responder consultas, identificar clientes potenciales, armar propuestas, revisar métricas. Ninguna de esas tareas es grande por sí sola. El problema es que todas terminan en las mismas manos, y buena parte de la jornada se va en coordinar: saber qué sigue, quién lo hace, qué quedó pendiente. Ese tiempo no genera valor nuevo, y ahí es donde un sistema multiagente empieza a tener sentido.

Cómo se vería un enjambre pequeño

Imagina cuatro agentes especializados. Uno investiga: busca información, analiza fuentes y resume hallazgos. Otro toma ese material y lo convierte en borradores de artículos, capacitaciones o publicaciones. Un tercero atiende consultas frecuentes apoyándose en una base de conocimiento. El cuarto, el comercial, lee las conversaciones, detecta oportunidades y las clasifica antes de pasarlas a una persona.

Si los dejamos trabajar sin orden, lo que tenemos son cuatro asistentes sueltos, no un sistema. Falta un supervisor: un agente que reciba la solicitud, interprete qué se necesita, reparta el trabajo, revise los resultados, pida correcciones y decida cuándo debe intervenir una persona. Una precisión que me parece importante: esto es un patrón de orquestador, y es el que yo elegiría en un entorno empresarial. Un enjambre completamente libre es más difícil de gobernar y de auditar.

La persona no desaparece, cambia de rol. Deja de ejecutar cada microtarea y pasa a supervisar, aprobar y decidir.

¿Por qué WhatsApp?

Gran parte de la IA se sigue diseñando pensando en una computadora, pero en Latinoamérica buena parte de la vida diaria ocurre en WhatsApp. Y no es un canal más: para mucha gente es una conversación directa. No sentimos que usamos un sistema, sentimos que hablamos con alguien.

Por eso conectar un sistema multiagente a WhatsApp me parece tan interesante. La persona escribe desde su teléfono, el sistema identifica qué quiere y responde si es una consulta sencilla. Si necesita documentación, otro agente la busca, y si aparece una oportunidad comercial, se prepara el contexto. Cuando hay que decidir algo, entra una persona. Por detrás hay arquitectura, pero por delante sigue siendo una conversación.

Una arquitectura posible en Azure

Llevado a un entorno empresarial, yo lo pensaría por capas. Los canales (WhatsApp, web, correo, redes) entrarían por Azure API Management y flujos en Logic Apps, con la seguridad resuelta desde el inicio mediante Microsoft Entra ID y Key Vault. La capa de inteligencia viviría en Azure AI Foundry, donde se implementa el agente orquestador y los especializados, apoyados en Azure Functions para las tareas concretas. El conocimiento de la organización (documentos, cursos, políticas) se consultaría con Azure AI Search. El estado de conversaciones y oportunidades iría en Azure SQL, Cosmos DB o Storage, según la necesidad. Y todo tendría que ser observable: con Application Insights registramos métricas, errores y tiempos de respuesta.

Esa última parte es la que separa una demo de una plataforma que se puede gobernar, medir y escalar.

Automatizar no es eliminar personas

Hay una idea que defiendo mucho: automatizar no significa sacar a las personas del proceso, y en muchos casos tampoco sería recomendable. El diseño debe incluir puntos claros de human in the loop. Un agente prepara la publicación y una persona la aprueba. Un agente responde una consulta, pero las preguntas sensibles se derivan. Un agente detecta una oportunidad comercial y una persona decide cómo continuar la conversación. Así se gana velocidad sin perder control.

¿Realmente ahorramos algo?

Una arquitectura se ve muy bien en un diagrama. La pregunta de negocio es otra: ¿mejora el proceso? Para responderla necesitamos un baseline.

Tomemos un costo referencial de US$25 por hora. Un ciclo manual de investigación, redacción, materiales, atención de consultas y gestión de oportunidades podría consumir unas 10 horas, es decir, US$250. Si los agentes ejecutan parte del trabajo en paralelo y la persona se concentra en supervisar y validar, el mismo ciclo podría requerir unas 3 horas humanas efectivas: US$75. La diferencia serían 7 horas y unos US$175 por ciclo.

Son cifras de ejemplo, y ese ahorro es bruto. Para llegar al neto habría que restar lo que cuesta construir el sistema, el consumo de los modelos, el mantenimiento y el tiempo de revisión humana. Por eso cada organización debe medir su propio proceso antes de automatizar, volver a medir después y recién entonces hablar de productividad.

Lo que me parece realmente valioso

Para mí, el potencial de los sistemas multiagente no está en tener muchos agentes ni en una arquitectura llamativa. Está en algo más simple: reducir la coordinación manual entre tareas que ya sabemos hacer. Que el sistema investigue mientras atendemos otra cosa, que prepare un borrador mientras resolvemos un problema, que clasifique consultas mientras desarrollamos un producto, y que solo nos deje las decisiones importantes. Lo que recuperamos es tiempo, uno de los recursos más escasos, para desarrollar productos, estudiar, hablar con clientes o simplemente pensar.

Primero usamos la IA para responder preguntas, después para ejecutar tareas, y ahora empezamos a usarla para coordinar trabajo. Por eso me quedo con esta pregunta: ¿qué parte de nuestro trabajo seguimos coordinando manualmente sin necesidad?

¿Puede existir una IA que no pertenezca a nadie?

2026-10-03T14:00:18.119-07:00

¿Puede existir una IA que no pertenezca a nadie?

Hoy usamos inteligencia artificial de una forma bastante parecida a como usamos la electricidad: hacemos una solicitud y esperamos una respuesta.

Pero hay una diferencia importante.

Detrás de ChatGPT, Claude, Gemini y otros modelos existe una organización que controla la infraestructura, decide qué modelos están disponibles, establece las condiciones de uso y, finalmente, puede cambiar las reglas.

Por eso me hice una pregunta:

¿Podría existir una inteligencia artificial que no pertenezca a una sola organización?

Hasta hace poco habría parecido una discusión teórica. Ya no lo es.

Un modelo entrenado sin un único data center

A finales de 2024 ocurrió algo que pasó casi desapercibido fuera del mundo de investigación en IA.

Prime Intellect coordinó el entrenamiento de INTELLECT-1, un modelo de 10 mil millones de parámetros entrenado sobre un billón de tokens.

Lo interesante no fue solamente el modelo.

Fue dónde se entrenó.

Participaron 30 proveedores independientes de cómputo, con hasta 14 nodos trabajando simultáneamente y 112 GPUs H100 distribuidas entre cinco países y tres continentes. El entrenamiento alcanzó una utilización de cómputo del 83 % entre continentes y del 96 % cuando los nodos estaban distribuidos dentro de Estados Unidos.

No existía un único gran centro de datos conteniendo todas las GPUs.

El entrenamiento estaba repartido por Internet.

Y eso plantea una posibilidad interesante: quizás entrenar modelos grandes no tenga que ser siempre una capacidad exclusiva de unas pocas organizaciones con enormes centros de datos.

El problema no eran las GPUs

Hay una razón técnica por la que entrenar un modelo de esta manera es difícil.

Las GPUs necesitan intercambiar constantemente información durante el entrenamiento. Cuando están dentro del mismo data center pueden hacerlo mediante redes extremadamente rápidas.

Cuando están separadas por miles de kilómetros, Internet se convierte en el cuello de botella.

El equipo de Prime Intellect atacó precisamente ese problema.

Su framework PRIME permite trabajar con nodos que pueden incorporarse o desaparecer durante el entrenamiento. Además, utilizando DiLoCo y mecanismos de comunicación optimizados consiguieron reducir aproximadamente 400 veces el ancho de banda necesario frente al entrenamiento distribuido tradicional.

Y aquí aparece una lección de arquitectura que me parece mucho más interesante que el propio modelo:

el problema no era solamente cuánto cómputo existía, sino cuánto necesitaban comunicarse las máquinas entre sí.

Reducir esa comunicación permitió distribuirlas geográficamente.

INTELLECT-1 no compite con los modelos comerciales más avanzados. Tampoco demuestra que mañana podamos reemplazar los grandes data centers por computadoras conectadas desde nuestras casas.

Demuestra algo más básico y quizá más importante:

es técnicamente posible entrenar colaborativamente un modelo grande utilizando infraestructura distribuida por el mundo.

Pero distribuir el cómputo no distribuye la confianza

Aquí aparece el siguiente problema.

Supongamos que una máquina que no conozco participa en el entrenamiento o procesa una inferencia.

¿Cómo sé que realmente ejecutó el modelo que debía ejecutar?

¿Cómo sé que no modificó el cálculo?

¿Cómo puedo comprobar el resultado?

En una arquitectura centralizada resolvemos buena parte de ese problema confiando en una organización: tenemos contratos, SLA, auditorías y alguien responsable del servicio.

En una arquitectura descentralizada esa confianza debe construirse técnicamente.

Y ahí aparece otro proyecto interesante: Gensyn.

En septiembre de 2026 presentó open-1b, un modelo cuyo proceso de entrenamiento puede ser auditado. Cada paso genera una huella que puede publicarse y posteriormente reproducirse para comprobar que el entrenamiento ocurrió como se declaró.

Hay un detalle importante: open-1b no fue entrenado de forma descentralizada.

Gensyn centralizó el entrenamiento y descentralizó la capacidad de verificarlo.

Eso cambia ligeramente la pregunta.

En lugar de:

"¿Confío en quien entrenó este modelo?"

podríamos empezar a preguntar:

"¿Puedo comprobar lo que hizo?"

Gensyn también experimenta con inferencia distribuida. Su prototipo IR3DE-AXL permite que distintos participantes aporten modelos especializados y que cada usuario construya localmente su propio mecanismo para decidir qué experto utilizar.

Un nodo podría ofrecer un modelo especializado en programación, otro uno matemático y otro uno generalista. No existe necesariamente un gateway central decidiendo por todos.

Pero todavía es un experimento. El propio proyecto reconoce que el prototipo no incorpora mecanismos completos de verificación, reputación o incentivos.

Y justamente ahí está el problema que aún falta resolver.

Descentralizado no significa sin dueño

Existe otra aproximación: Bittensor.

Bittensor organiza una red de subnets donde diferentes participantes pueden producir servicios digitales —incluidos servicios relacionados con IA— y otros participantes evalúan ese trabajo. Los incentivos se distribuyen mediante la economía de la red.

Pero aquí aparece una distinción importante.

Cada subnet tiene un propietario que define su mecanismo de incentivos y cómo deben evaluarse los participantes. Además, la capacidad de validación está relacionada con el stake y los permisos de la red.

Por eso decir simplemente “IA sin dueño” puede ser engañoso.

Descentralizar no significa eliminar el poder.

Significa distribuirlo de otra manera.

¿Y qué significa esto para una empresa?

No creo que mañana un banco deba enviar información de clientes a una red de GPUs desconocidas repartidas por Internet.

La descentralización no es un interruptor que se enciende. Es una arquitectura que puede construirse por capas.

Una organización podría mantener información sensible y determinados modelos dentro de su propia infraestructura; utilizar proveedores cloud para cargas generales; colocar una capa de abstracción que permita cambiar de modelo o proveedor; y experimentar con redes distribuidas únicamente utilizando información no sensible.

Ese enfoque conecta además con otra tendencia que ya he comentado anteriormente: Edge AI.

Edge AI pregunta principalmente dónde ejecutamos la inteligencia.

La IA descentralizada agrega otra pregunta:

¿quién tiene que controlar la infraestructura que la hace posible?

Y ambas terminan llevando al mismo objetivo: reducir dependencias innecesarias.

Entonces, ¿puede existir una IA que no pertenezca a nadie?

Después de revisar estos proyectos, creo que esa pregunta está ligeramente equivocada.

Probablemente siempre existirán propietarios de infraestructura, desarrolladores, operadores, protocolos y mecanismos de gobierno.

Lo interesante no es construir una inteligencia que literalmente no pertenezca a nadie.

Es construir una en la que nadie tenga que ser dueño de todo.

INTELLECT-1 demostró que diferentes participantes pueden aportar cómputo para entrenar conjuntamente un modelo.

Gensyn está explorando cómo reemplazar parte de la confianza por verificabilidad.

Bittensor experimenta con mecanismos económicos para coordinar participantes independientes.

Todavía faltan SLA, responsabilidades legales, privacidad, regulación y modelos de gobernanza capaces de funcionar a escala empresarial.

Pero la dirección ya puede verse.

Internet no creció porque una empresa construyera la computadora más grande del mundo. Creció porque millones de sistemas independientes aprendieron a comunicarse mediante protocolos comunes.

Quizá con la inteligencia artificial termine ocurriendo algo parecido.

Y entonces la pregunta más interesante dejará de ser quién posee la IA más poderosa.

Será quién puede participar en construirla.

Fuentes:

Prime Intellect · Informe INTELLECT-1 (arXiv) · Arcee AI · Hugging Face, INTELLECT-1 · Gensyn, open-1b · Informe OPEN-1B (arXiv) · Gensyn, IR3DE-AXL · Gensyn Docs · Bittensor Docs

¿Y si mañana no tienes ChatGPT, Claude o Gemini?

2026-09-16T19:30:57.514-07:00

¿Y si mañana no tienes ChatGPT, Claude o Gemini?

Edge AI no solo puede reducir costos y proteger datos. También puede formar parte de una estrategia de continuidad.

Cada vez que utilizamos ChatGPT, Claude, Gemini o cualquier otro modelo alojado en la nube, estamos delegando una parte de nuestro trabajo a infraestructura que no controlamos. En algunos casos se trata apenas de una consulta ocasional, pero en otros la inteligencia artificial empieza a integrarse en procesos empresariales completos: atención al cliente, análisis de documentos, generación de reportes, soporte al desarrollo, clasificación de información o procesamiento de audio.

Mientras el servicio está disponible, la arquitectura parece funcionar perfectamente. El problema aparece cuando deja de estarlo.

No hace falta imaginar que OpenAI, Google o Anthropic desaparezcan. Basta con una caída de servicio, un problema de conectividad, un cambio de precios, un límite de consumo, una modificación de API, una nueva política sobre el tratamiento de datos o la retirada de una versión del modelo sobre la que construimos nuestra aplicación.

Si el proceso depende completamente de ese servicio externo, la indisponibilidad del modelo deja de ser un problema técnico y empieza a convertirse en un riesgo operativo.

Y ahí aparece una pregunta que probablemente tendremos que empezar a incorporar con mayor frecuencia al diseñar soluciones de inteligencia artificial: si mañana el modelo que utilizamos deja de estar disponible, ¿qué parte de nuestra operación puede seguir funcionando?

De la dependencia del modelo a la arquitectura

Durante años hemos aprendido a diseñar sistemas pensando en disponibilidad, redundancia, recuperación y continuidad. Implementamos clusters, balanceadores, backups, replicación, enlaces alternativos, recuperación ante desastres y procedimientos de contingencia porque sabemos que ningún componente tecnológico debería considerarse infalible.

Sin embargo, muchas de las primeras arquitecturas construidas alrededor de inteligencia artificial vuelven a introducir una dependencia bastante sencilla:

Aplicación → API → LLM.

Si el modelo responde, todo funciona. Si no responde, el proceso se detiene.

El problema no está en utilizar un servicio cloud. El cloud ofrece capacidades extraordinarias y, para determinadas tareas, probablemente seguirá siendo la mejor alternativa. El problema aparece cuando un proceso crítico depende de un único proveedor, de una única API o incluso de una única forma de ejecutar la inteligencia que necesita.

Por eso Edge AI empieza a ser interesante no solamente desde la perspectiva de privacidad o rendimiento, sino también desde el punto de vista de arquitectura y gestión del riesgo.

La idea de Edge AI consiste en ejecutar parte de la inteligencia mucho más cerca de donde se generan los datos, ya sea en un dispositivo, un servidor local, un gateway o infraestructura propia. No significa necesariamente eliminar la nube ni intentar reproducir localmente las capacidades de los modelos más grandes del mercado. En muchos casos significa algo bastante más práctico: determinar qué funciones realmente necesitan depender de la nube y cuáles pueden mantenerse disponibles localmente.

Desde esa perspectiva, la discusión deja de ser “cloud versus local” y se convierte en una decisión de distribución de capacidades.

No todo necesita el modelo más grande

Uno de los argumentos habituales a favor de los grandes modelos de lenguaje es su enorme capacidad generalista. Pueden redactar, resumir, programar, analizar textos, conversar sobre prácticamente cualquier tema y resolver problemas que requieren niveles importantes de razonamiento.

Pero no todos los procesos empresariales necesitan esa amplitud.

Una organización que clasifica determinados documentos, extrae información de formatos conocidos, procesa audio, identifica patrones concretos o consulta una base documental interna podría obtener resultados satisfactorios utilizando modelos más pequeños o especializados. En algunos casos esos modelos pueden complementarse con información propia mediante RAG, ajustarse para una tarea específica o integrarse con reglas y componentes tradicionales.

La pregunta entonces no debería ser únicamente cuál es el modelo más potente que podemos utilizar, sino cuál es el nivel de inteligencia que realmente necesita cada parte del proceso.

Esta diferencia importa porque un modelo local puede reducir dependencias que desaparecen cuando toda la inferencia ocurre en infraestructura propia. Ya no es necesario enviar cada operación a una API externa, y determinadas funciones pueden seguir disponibles incluso ante problemas de conectividad o indisponibilidad del proveedor.

Naturalmente, esto no convierte a Edge AI en una solución mágica. El servidor puede fallar, la GPU puede presentar problemas, el almacenamiento puede quedar indisponible y los modelos necesitan actualización, monitoreo y seguridad. La privacidad tampoco deja de ser un problema simplemente porque los datos permanezcan localmente: siguen existiendo riesgos relacionados con accesos, respaldos, credenciales, logs y administración de infraestructura.

El riesgo no desaparece. Cambia de manos.

Y precisamente ahí está una de las decisiones arquitectónicas más interesantes.

Lo que estoy viendo con ELISA

Trabajando en ELISA me encontré con esta decisión de una manera bastante práctica. Para determinadas capacidades opté por utilizar infraestructura propia y ejecutar modelos localmente en lugar de convertir cada operación en una llamada hacia un servicio externo.

Una de las razones iniciales fue el costo. Cuando ya existe capacidad de cómputo disponible, determinadas cargas pueden ejecutarse localmente sin generar un costo variable por cada token, consulta o minuto procesado. Esto no significa que la infraestructura local sea siempre más económica; mantener hardware también tiene costos de adquisición, electricidad, administración, almacenamiento y mantenimiento. La relación depende del volumen, del tipo de modelo y de la carga de trabajo.

Sin embargo, al trabajar con esta arquitectura apareció otra ventaja que inicialmente no era tan evidente: algunas funciones dejan de depender de que una API externa esté disponible.

ELISA Transcribe, por ejemplo, procesa audio utilizando infraestructura propia para realizar la transcripción. Esto permite controlar mejor el flujo de procesamiento y evita que el núcleo del servicio dependa exclusivamente de una plataforma externa para ejecutar esa función.

La experiencia también deja claro el otro lado de la ecuación. Cuando la inteligencia se ejecuta sobre infraestructura propia, también asumimos responsabilidades que antes pertenecían al proveedor: capacidad, monitoreo, disponibilidad, actualizaciones, seguridad y recuperación.

Por eso no veo Edge AI como una competencia contra la nube. Lo veo como una opción adicional dentro de una arquitectura más resiliente.

Diseñar una IA que pueda degradarse sin detenerse

En sistemas tradicionales existe un concepto bastante conocido: operación degradada. Cuando un componente falla, el sistema puede perder algunas capacidades, pero mantiene disponibles las funciones esenciales.

Podríamos empezar a aplicar el mismo principio a las arquitecturas de inteligencia artificial.

Una aplicación podría utilizar normalmente un modelo cloud de altas capacidades para tareas complejas, pero mantener un modelo local para funciones básicas o críticas. Si el proveedor principal deja de estar disponible, el sistema no tendría necesariamente que comportarse exactamente igual; podría entrar temporalmente en un modo de operación limitado.

La arquitectura podría incluso combinar varios niveles: un modelo principal en la nube, otro proveedor como alternativa, modelos locales para determinadas funciones y, cuando corresponda, procedimientos manuales para situaciones excepcionales.

No todas las organizaciones necesitan esa complejidad. Un asistente utilizado ocasionalmente para mejorar la redacción de correos probablemente no requiere un plan de recuperación. Pero la situación cambia cuando la inteligencia artificial empieza a participar directamente en procesos de negocio cuya interrupción tiene consecuencias económicas u operativas.

En ese momento, el modelo deja de ser simplemente una herramienta y pasa a ser parte de la arquitectura.

Edge AI también puede ser una estrategia de riesgo

Cuando hablamos de Edge AI solemos concentrarnos en tres beneficios: menor latencia, mayor privacidad y menor dependencia de conectividad. Son argumentos importantes, pero quizá estamos dejando fuera otro igualmente relevante.

La continuidad.

Una estrategia de inteligencia artificial madura no debería limitarse a decidir qué modelo utilizar. También debería considerar qué ocurre cuando ese modelo no está disponible, qué funciones realmente requieren conectividad permanente, qué cargas pueden ejecutarse localmente y qué capacidades mínimas deberían mantenerse si falla el proveedor principal.

Eso no significa que todas las empresas deban instalar GPUs en sus oficinas ni desarrollar sus propios modelos. En muchos casos la mejor arquitectura seguirá siendo completamente cloud. En otros, una combinación de modelos externos y locales puede ofrecer un equilibrio más razonable entre capacidad, costo, privacidad y disponibilidad.

Lo importante es que esa decisión sea consciente y forme parte del diseño.

Hace tiempo dejamos de diseñar infraestructura suponiendo que un servidor nunca iba a fallar. Tal vez también tengamos que dejar de diseñar soluciones de inteligencia artificial suponiendo que el modelo que utilizamos hoy siempre estará disponible exactamente en las mismas condiciones.

Porque a medida que la IA se integra en procesos cada vez más importantes, la pregunta ya no es solamente qué modelo utilizamos.

También tendremos que preguntarnos:

Si mañana desapareciera el LLM del que depende mi solución, ¿mi operación seguiría en pie?

El riesgo silencioso de una IA que responde con información desactualizada

2026-09-04T16:10:06.772-07:00

El riesgo silencioso de una IA que responde con información desactualizada

Estamos cada vez más acostumbrados a confiarle a la IA nuestras decisiones. En el trabajo, en el día a día, hasta en temas personales le preguntamos y actuamos según lo que responde.

Pero, ¿qué pasaría si un agente te da información que a primera vista parece confiable, con una fuente real detrás, pero en realidad tiene dos años de antigüedad o más?

Imagina que ese agente está en el portal de un banco, una clínica o una entidad del Estado. Y que, en base a esa respuesta, tomas una decisión.

¿Te imaginas que fuera la información para inscribirte a un evento, sacar una cita médica o pagar un impuesto? Que el agente te confirme una fecha, un requisito o un monto que ya no aplica, y tú lo tomes como válido porque, bueno, te lo dijo la IA.

Ese es el escenario que quiero desarrollar hoy, porque no es ciencia ficción. Es un riesgo real, silencioso, y que casi nadie está diseñando para prevenir.

No es una alucinación, y eso es lo grave

Cuando hablamos de errores de IA generativa, lo primero que se nos viene a la mente es la alucinación: el modelo inventa una fuente, cita un dato que no existe, construye una respuesta con seguridad absoluta sobre algo que jamás verificó. Ya aprendimos a desconfiar cuando algo se ve raro.

Este otro error es distinto y más peligroso, justamente porque no se ve raro. El documento existe. La fuente citada es real. El agente la interpretó correctamente. Todo pasa cualquier revisión superficial sin problema.

El error no está en lo que el modelo inventó. Está en lo que el sistema decidió que era la mejor información disponible, sin darse cuenta de que ya no estaba vigente.

Por qué el sistema no distingue esto

La mayoría de estos agentes funcionan con una arquitectura de RAG (Retrieval-Augmented Generation): antes de responder, el sistema busca en una base de documentos.

El problema está en ese segundo paso. Los documentos se dividen en fragmentos y cada fragmento se convierte en una representación numérica de su significado. Cuando alguien pregunta algo, el sistema recupera los fragmentos que más se parecen semánticamente a esa pregunta, no cuáles siguen vigentes.

Imagina dos versiones del mismo procedimiento, una de hace dos años y su reemplazo reciente. Comparten casi el mismo vocabulario, la misma estructura, el mismo tema.

Para el sistema, ambas son candidatas casi perfectas. No tiene ninguna noción incorporada de que una reemplazó a la otra. Simplemente elige la que matemáticamente se acerca más a la pregunta, sin importarle cuál sigue siendo válida hoy.

El modelo que redacta la respuesta final tampoco puede corregir esto, porque para cuando el texto llega a sus manos, ya fue seleccionado. El error no ocurre durante la redacción. Ocurre antes, en la selección del conocimiento que se le permitió usar.

Lo que casi nadie diseña

Hay tres piezas que suelen faltar en estas implementaciones, y son justamente las primeras que se dejan para después:

Metadata temporal. No basta con que un archivo se llame "version_final_2026.pdf". El sistema necesita campos estructurados: fecha de vigencia, fecha de expiración, estado, qué versión reemplazó a cuál. Sin esos datos, para el sistema todas las versiones son igual de válidas.

Una fuente única de verdad. En muchas organizaciones conviven varias versiones de un mismo documento en distintas carpetas, con nombres como "final", "final2" y "nueva". Una persona con experiencia puede intuir cuál usar. El sistema no puede, a menos que se lo digamos explícitamente.

Una capa de validación entre la búsqueda y la respuesta. La búsqueda semántica encuentra candidatos. Decidir cuáles de esos candidatos pueden usarse debería ser una regla determinista, no algo que dependa de qué tan convincente suene el texto.

La arquitectura que sí lo resuelve

Aquí es donde muchas organizaciones se equivocan de diagnóstico. Cuando un agente comete este tipo de error, la reacción natural es pensar que hace falta un modelo más grande o más nuevo. Pero un modelo más potente no resuelve nada si sigue recibiendo el mismo contexto mal seleccionado.

La solución agrega un paso entre la búsqueda semántica y la generación de la respuesta:

Solo lo que pasa esa validación llega al modelo como contexto autorizado. Versiones, estados y fechas se verifican con reglas simples y deterministas, no con el criterio del modelo.

Y hay una segunda pieza igual de importante: el agente debe tener permitido no responder. Cuando no existe una fuente vigente y confiable, la respuesta correcta puede ser simplemente decir que no se puede confirmar esa información en este momento. Muchos agentes terminan diseñándose, implícita o explícitamente, para intentar responder siempre. Y una respuesta incompleta pero honesta es infinitamente mejor que una respuesta completa construida sobre información que ya caducó.

La arquitectura empieza antes del modelo

No comparto este caso solo como advertencia técnica. Lo comparto porque creo que esta es exactamente la conversación que todavía no estamos teniendo con la profundidad que necesita, mientras nos apuramos por implementar IA generativa, mostrar casos de uso y no quedarnos atrás.

Un agente de IA en una institución que maneja citas, trámites, pagos o aprobaciones no es un experimento de innovación aislado. Es un sistema que puede terminar influyendo decisiones reales de las personas que confían en él. Y si algo he aprendido en más de quince años trabajando con sistemas críticos es que la gestión documental descuidada, con IA o sin IA, tarde o temprano se paga caro.

La pregunta que deberíamos estar haciéndonos ya no es solo qué tan inteligente es el modelo que estamos usando. Es qué información le estamos permitiendo usar, con qué reglas, y qué pasa cuando esa información deja de ser válida. Ese diseño no lo resuelve un mejor prompt ni un modelo más nuevo. Lo resuelve arquitectura, gobierno documental y sentido común aplicado con disciplina.

¿Y si el atacante ya entró? La pregunta que separa la ciberseguridad de la ciberresiliencia

2026-08-31T14:37:24.144-07:00

¿Y si el atacante ya entró? La pregunta que separa la ciberseguridad de la ciberresiliencia

Firewall. WAF. EDR. MFA. SIEM. Si su organización tiene todo eso desplegado y funcionando, probablemente se siente protegida.

Y sin embargo, esa misma organización puede no sobrevivir a un ataque exitoso.

No porque las herramientas fallen, sino porque responden a una pregunta distinta de la que realmente importa. La ciberseguridad tradicional pregunta "¿cómo evitamos que el atacante entre?". La ciberresiliencia parte de una pregunta más incómoda:

¿Qué pasa si entra de todas maneras?

¿Puede moverse lateralmente? ¿Llega a comprometer identidades privilegiadas? ¿Alcanza los backups? ¿Cuánto del negocio sigue operando mientras se contiene el incidente? ¿Desde dónde se recupera, y en cuánto tiempo?

Esta es la tesis: muchas empresas creen que están seguras porque invirtieron en impedir la entrada. Pocas se han preparado para lo que pasa después de que alguien entra igual. Y con IA generativa acelerando el phishing dirigido, la automatización de reconocimiento y la velocidad con la que se explotan vulnerabilidades nuevas, esa probabilidad de "entrar igual" ya no es una posibilidad remota. Es, cada vez más, cuestión de tiempo.

Dos arquitecturas, una misma organización

La mayoría de organizaciones tiene, en la práctica, algo así:

No hay nada mal en esto. Cada componente es necesario. El problema no es tenerlos: es asumir que tenerlos es la resiliencia.

Esta es una arquitectura preventiva. Está optimizada para reducir la probabilidad de que el atacante entre. No responde qué pasa cuando entra igual, y estadísticamente, tarde o temprano, entra.

Una arquitectura resiliente parte del mismo perímetro, pero con otra lógica:

Prevent → Detect → Contain → Continue → Recover → Evolve

Se asume que el intento de intrusión va a ocurrir (Prevent), que en algún punto tendrá éxito parcial (Detect), y que a partir de ahí lo que define la supervivencia del negocio es qué tan rápido se limita el daño (Contain), qué tan bien sigue operando lo esencial mientras eso pasa (Continue), qué tan rápido se restablece el servicio (Recover) y qué tanto cambia la arquitectura después del incidente (Evolve).

En alto nivel, se vería así:

La diferencia entre ambas arquitecturas no está en los productos. Está en el diseño de las rutas de falla: qué pasa cuando un componente cae, y qué tan lejos puede llegar ese daño antes de que algo más lo contenga.

Blast radius: la pregunta que cambia el diseño

No se trata solo de evitar que un atacante entre. Se trata de limitar cuánto daño puede causar una identidad, un endpoint o un segmento comprometido antes de ser contenido. A esto se le llama blast radius: el radio de impacto.

El ransomware expone esto con crudeza. Un atacante que compromete una sola credencial no necesita "romper" el firewall: si esa credencial tiene acceso amplio, sin segmentación ni control de identidades privilegiadas, puede moverse lateralmente hasta alcanzar sistemas críticos y, con frecuencia, los propios backups.

Y ahí está el punto central: un backup que el atacante puede cifrar junto con producción no es una estrategia de recuperación. Es una copia adicional del mismo problema. Por eso los backups inmutables, las copias aisladas y el control de accesos privilegiados (PAM) no son "extras" de seguridad: son la diferencia entre recuperarse en horas o negociar con un atacante porque no queda otra opción.

La pregunta correcta no es únicamente "¿cómo evitamos la intrusión?". Es: ¿la arquitectura permite que una parte de la organización sea comprometida sin que toda la empresa deje de operar?

Lo que esto le cambia al Project Manager

Soy PMP y he gestionado proyectos tecnológicos y de ciberseguridad. Durante años el foco fue alcance, cronograma, presupuesto, riesgos y proveedores. Eso sigue siendo necesario y no va a dejar de serlo.

Pero dirigir un proyecto de infraestructura o ciberseguridad sin entender la arquitectura tiene un costo concreto. Es la diferencia entre firmar un cronograma y poder cuestionarlo con criterio:

¿Qué dependencias reales existen entre esta capa y la siguiente, más allá de las que aparecen en el diagrama del proveedor?
¿Qué supuesto está dando por sentado el equipo técnico que nadie ha verificado?
¿Dónde está el single point of failure que no se mencionó en el kickoff?
Si cambiamos este componente, ¿qué más se mueve con él?
¿Puedo sostener una conversación técnica con el arquitecto o el especialista de seguridad sin depender de que me traduzcan todo?
¿Esta decisión técnica en qué afecta la continuidad del negocio, no solo el cronograma del proyecto?

Un PM que no puede responder estas preguntas termina gestionando actas, fechas y proveedores, mientras las decisiones que realmente definen el proyecto se toman sin él. Un PM que sí puede responderlas se vuelve el puente entre negocio y arquitectura — y ese es un lugar mucho más difícil de reemplazar.

El PM tecnológico del futuro necesita aumentar progresivamente su profundidad técnica. No para dejar de ser PM, sino porque esa profundidad es lo que abre la puerta hacia Solution Architecture, Cybersecurity Architecture o AI Architecture. Es, en buena medida, el camino que yo misma vengo recorriendo.

El cierre

La ciberseguridad tradicional mide el éxito por lo que impidió. La ciberresiliencia lo mide por lo que la organización sigue pudiendo hacer después de que algo salió mal. Ninguna arquitectura, por bien construida que esté, elimina el riesgo de una intrusión. La pregunta que de verdad separa a las organizaciones no es si tienen firewall, sino si diseñaron algo capaz de seguir en pie cuando el firewall ya no fue suficiente.

La ciberseguridad ya no es un proyecto de defensa. Es una carrera de IA contra IA.

2026-08-25T09:45:39.411-07:00

La ciberseguridad ya no es un proyecto de defensa. Es una carrera de IA contra IA

Durante años, un proyecto de ciberseguridad tenía un punto de llegada razonablemente claro: se definían los controles, se implementaban, se documentaban, y el proyecto se cerraba con esos controles operando. La amenaza cambiaba, sí, pero a un ritmo que permitía tratarla como un problema de mantenimiento periódico, no como una variable en movimiento constante.

Eso terminó. Lo que está ocurriendo ahora no es simplemente que aparecieron amenazas nuevas. Es que el propio objeto del proyecto cambió de naturaleza. Ya no se está construyendo un conjunto fijo de controles frente a un adversario relativamente estático. Se está sosteniendo una capacidad que necesita evolucionar al mismo ritmo que evoluciona quien la ataca, porque ese adversario también tiene acceso a inteligencia artificial. Lo que tenemos hoy es, literalmente, una carrera: IA ofensiva contra IA defensiva, corriendo en paralelo, sin línea de meta.

Esto cambia el tipo de proyecto que hay que diseñar. Un proyecto de ciberseguridad ya no puede plantearse como "implementar estos controles" sino como "sostener una capacidad de adaptación", lo cual es un problema de gestión completamente distinto: distinto en alcance, en cronograma, en la forma de medir éxito y en el tipo de gobierno que necesita.

Cinco términos que conviene tener claros

Antes de entrar en lo que esto implica para quien gestiona proyectos, vale la pena aterrizar algunos conceptos que están detrás de esta carrera, porque no todos los que se sientan en la mesa de decisión vienen de un perfil técnico.

Deepfakes. Contenido de audio, video o imagen generado o alterado por IA para hacer parecer que una persona dijo o hizo algo que nunca ocurrió. La tecnología que hace esto posible es, en esencia, la misma que se usa para generar avatares, doblaje automático o efectos audiovisuales legítimos; el problema no es la herramienta, es el uso.

Ataques de ingeniería social más personalizados. La ingeniería social siempre existió: manipular a una persona para que entregue acceso, información o dinero. Lo que cambió es la escala de personalización posible. Un modelo de lenguaje puede redactar un mensaje sin errores, adoptar el tono exacto de un proveedor conocido o construir un pretexto ajustado al cargo y al contexto específico de la víctima, algo que antes tomaba investigación manual y tiempo.

Malware adaptable. Software malicioso capaz de modificar su propio comportamiento o su código para evitar ser reconocido por las herramientas de detección tradicionales, que suelen buscar patrones o firmas conocidas. En lugar de un virus con una "firma" fija, se enfrenta algo que cambia de forma mientras opera.

Automatización del reconocimiento de vulnerabilidades. La fase en la que un atacante identifica puntos débiles en un sistema —configuraciones abiertas, software desactualizado, accesos mal protegidos— antes existía y era mayormente manual. La IA permite escanear volúmenes enormes de sistemas en busca de esas debilidades de forma automatizada y continua, comprimiendo un trabajo de semanas en un proceso que corre de fondo.

Jailbreaking. Cuando una organización incorpora un modelo de IA, no solo agrega una nueva capacidad: también agrega una nueva superficie de ataque. Un jailbreak consiste en manipular al modelo para que ignore las restricciones con las que fue diseñado y responda o actúe de una forma que normalmente debería rechazar. El riesgo real no está en lograr que un chatbot conteste algo indebido, sino en lo que hay conectado detrás de ese modelo: si tiene acceso a documentos internos, bases de datos, APIs o procesos empresariales, alterar su comportamiento puede convertirse en un problema de seguridad concreto, no solo conversacional.

Un concepto asociado es el prompt injection: una instrucción maliciosa que busca alterar el comportamiento esperado del modelo, a veces de forma directa y a veces escondida dentro de un documento, un correo o cualquier contenido que la IA procese sin que el usuario lo note. Para quien gestiona el proyecto, la conclusión es simple: las instrucciones del modelo no pueden considerarse por sí mismas un control de seguridad. Los permisos, accesos, segregación de funciones y límites sobre las acciones que el modelo puede ejecutar siguen siendo indispensables.

La defensa también está aprendiendo

Lo que suele quedar fuera de la conversación es que este mismo cambio está ocurriendo del lado defensivo, y con un nivel de madurez que ya no es experimental. Los equipos de seguridad utilizan modelos de IA para detectar anomalías de comportamiento en tiempo real —patrones de acceso o tráfico que se apartan de lo esperado—, para automatizar la clasificación inicial de alertas en un centro de operaciones de seguridad, reduciendo el volumen que antes requería revisión humana caso por caso, y para simular ataques contra sus propios sistemas de forma controlada, con el objetivo de encontrar las debilidades antes de que lo haga alguien externo.

También se está avanzando en biometría de comportamiento —analizar no solo si la contraseña es correcta, sino si el patrón de uso de quien la ingresó es consistente con el usuario legítimo— y en tecnologías de "engaño" (deception technology), que consisten en desplegar sistemas señuelo dentro de la red para detectar movimiento no autorizado antes de que llegue a un activo real.

Ninguna de estas capacidades es infalible, y ese es precisamente el punto: no existe una solución que cierre la carrera de forma definitiva. Cada avance defensivo genera presión para que la ofensiva se sofistique, y cada avance ofensivo obliga a ajustar la defensa. Es una dinámica de coevolución, no un problema que se resuelve una vez y queda resuelto.

La oportunidad de servicio que esto abre

Esta dinámica tiene una consecuencia menos evidente, pero especialmente relevante para quienes diseñan y comercializan proyectos de ciberseguridad. Durante mucho tiempo el ciclo comercial fue bastante lineal: primero se implementaba una solución, y después, si el cliente lo requería, se ofrecía un servicio de seguridad gestionada para operarla, monitorearla y atenderla. Una carrera entre capacidades ofensivas y defensivas introduce una necesidad adicional: no basta con operar el control, también hay que comprobar de forma periódica que sigue siendo efectivo frente a amenazas que no dejan de evolucionar.

Esto cambia la conversación de preventa. Un proyecto puede implementar correctamente una plataforma de protección, monitoreo o respuesta y cumplir todos sus entregables, y aun así, meses después, el panorama de amenazas ya cambió, aparecieron nuevas técnicas o surgieron escenarios que inicialmente no se contemplaron. Ahí empieza a cobrar valor una capa adicional de servicio: la validación continua de la capacidad defensiva. No se trata únicamente de mantener la herramienta funcionando, sino de someter la defensa a nuevas pruebas de forma periódica, revisar escenarios emergentes, identificar brechas, ajustar controles y volver a validar su eficacia.

El valor que recibe el cliente también cambia. Ya no compra solamente tecnología ni operación. Compra la capacidad de comprobar que su defensa sigue respondiendo frente a un adversario que tampoco permanece quieto.

El proyecto puede cerrar. La capacidad no.

Esto no significa que los proyectos de ciberseguridad deban convertirse en iniciativas eternas. Un proyecto sigue necesitando alcance, presupuesto, entregables y una fecha de cierre. Lo que cambia es aquello que debe dejar preparado cuando termina.

Antes podía ser suficiente entregar el control implementado, documentado y operativo. En un entorno donde ataque y defensa evolucionan rápidamente, el proyecto debería dejar además definido cómo esa capacidad será evaluada y ajustada después del cierre. El ciclo empieza a parecerse menos a implementar → probar → entregar → cerrar, y más a implementar → probar → operar → validar → ajustar → volver a probar.

Eso afecta desde el diseño del servicio hasta el presupuesto y los indicadores con los que se mide su éxito. Una solución puede estar disponible el 99,9 % del tiempo y, aun así, haber perdido efectividad frente a determinadas amenazas. Por eso las métricas técnicas y operativas necesitan complementarse con una pregunta más incómoda: ¿la capacidad defensiva que implementamos sigue siendo efectiva frente al escenario de amenazas actual?

Para quien gestiona proyectos, el cambio no consiste en aprender a pensar como una inteligencia artificial ni en convertirse en especialista ofensivo. Consiste en reconocer que el entregable tecnológico es solo una parte del resultado: el proyecto también debe dejar una capacidad preparada para seguir evolucionando. Y para quien trabaja en preventa aparece una oportunidad igual de concreta: diseñar desde el inicio no solo la implementación y la operación posterior, sino también el mecanismo mediante el cual esa defensa seguirá siendo puesta a prueba.

La seguridad gestionada seguirá siendo necesaria —alguien tiene que operar las plataformas, analizar alertas, responder incidentes y mantener los controles funcionando—, pero mantener un control funcionando y comprobar que continúa siendo eficaz no son exactamente lo mismo. Esa diferencia, entre operar y validar, puede convertirse en uno de los cambios más importantes en la forma de diseñar servicios de ciberseguridad en los próximos años.

La pregunta que queda abierta

La carrera entre IA ofensiva e IA defensiva no tiene un punto en el que alguien gane de forma definitiva. Lo que sí puede definirse es quién se adapta más rápido: la organización cuyos proyectos de ciberseguridad están diseñados para evolucionar al mismo ritmo que la amenaza, o la que sigue tratando la seguridad como un capítulo que se cierra una vez y no se vuelve a abrir.

Si todos usamos IA, ¿dónde está tu ventaja competitiva?

2026-08-21T13:50:23.636-07:00

Si todos usamos IA, ¿dónde está tu ventaja competitiva?

Hace apenas un par de años, saber redactar un informe sólido, armar una presentación decente o construir una hoja de cálculo con lógica clara podía diferenciarte dentro de un equipo. Hoy cualquier persona con un teléfono y una cuenta gratuita puede pedirle a un modelo de IA que haga eso mismo en segundos. Y lo hará razonablemente bien.

Ese es el punto de partida incómodo que quiero poner sobre la mesa: si tú, tu competencia, tu jefe y el practicante que acaba de entrar tienen exactamente el mismo acceso a ChatGPT, Claude o Copilot, entonces tener acceso a IA dejó de ser una ventaja. Es un piso, no una diferencia.

Cuando la herramienta deja de diferenciarnos

Durante años asociamos productividad con acceso: quien tenía la mejor herramienta, el mejor software, la licencia más cara, llevaba ventaja. La IA generativa rompió esa lógica porque democratizó de golpe capacidades que antes tomaban formación, tiempo o presupuesto: escribir, resumir, analizar, programar, generar imágenes, organizar información.

El problema es que cuando una capacidad se vuelve universal, deja de explicar por qué alguien destaca sobre otro. Si millones de personas están usando esencialmente el mismo motor para producir contenido, lo que sale de ahí tiende a parecerse. No porque el modelo copie, sino porque su diseño lo empuja hacia lo más probable, lo más esperado, lo más promedio. Es útil, sí. Pero promedio no es ventaja.

Y aquí conviene ser honesta: tener acceso a IA no equivale a convertir IA en resultados. Esa distancia —entre poder usar la herramienta y realmente lograr algo con ella— es donde se está jugando ahora la diferencia profesional.

De usar IA a construir con IA

Conviene separar tres niveles que solemos mezclar sin darnos cuenta.

Usar IA es lo más común: abrir un chat, escribir un prompt, recibir una respuesta, copiarla o ajustarla un poco. Es legítimo y aumenta la productividad individual, pero termina ahí, en el intercambio puntual.

Construir con IA es otra cosa. Es tomar un modelo como componente dentro de un sistema más grande: definir reglas, diseñar un flujo, decidir qué se automatiza y qué necesita supervisión humana, integrar entradas y salidas, validar resultados. Aquí el modelo deja de ser el protagonista y pasa a ser una pieza.

Crear valor con IA es el nivel donde ese sistema efectivamente resuelve un problema real para alguien, de forma sostenida, no como demostración sino como solución que funciona en producción, con usuarios, con errores que se corrigen y con resultados que se pueden medir.

La mayoría de las organizaciones no necesita entrenar su propio modelo fundacional. La oportunidad real está en el segundo y tercer nivel: usar lo que ya existe como bloque de construcción de algo específico y útil.

Un ejemplo aplicado ayuda a aterrizar esto. En ELISA Transcribe, la parte de "usar IA" —convertir audio en texto— es apenas el punto de partida. Convertir esa capacidad en algo que alguien pueda usar de verdad requirió construir un flujo que recibe archivos, aplica reglas, valida condiciones antes de procesar y entrega un resultado ya utilizable, sin que la persona tenga que lidiar con el modelo directamente. El modelo hace una tarea; el producto resuelve un problema. Esa diferencia es, en el fondo, la ventaja de la que estamos hablando.

El modelo no es el producto

Vale la pena insistir en esto porque es fácil confundirlo, especialmente cuando la demo de un modelo nuevo parece resolverlo todo. Entre el problema inicial y el resultado útil hay un recorrido largo: diseño, reglas de negocio, interfaz, integración con otros sistemas, validación, seguridad, operación diaria, experiencia de quien lo usa. El modelo participa en un solo tramo de ese camino. Todo lo demás sigue siendo trabajo humano, y ahí es donde se construye diferenciación.

La IA como socio junior, no como autoridad final

Hay una idea que circula bastante en el mundo de la gestión de proyectos y que me parece útil, aunque con matices: pensar en la IA como un socio junior. Puede proponer alternativas, generar borradores, encontrar patrones, resumir volúmenes de información, incluso cuestionar una idea si se le pide explícitamente que lo haga. Lo que no puede hacer es aportar contexto real, priorizar con criterio propio ni asumir responsabilidad sobre el resultado. Eso sigue siendo trabajo del profesional, no del modelo.

No se trata de afirmar que la IA nunca podrá razonar o que jamás avanzará; esa discusión no aporta nada al problema práctico que enfrentamos hoy. Lo que importa es más concreto: quién decide qué vale la pena resolver, quién entiende el contexto real detrás del pedido, y quién se hace cargo cuando el resultado no funciona.

Lo que sigue siendo escaso

Pedirle a una IA que produzca un documento, una presentación o un análisis toma minutos. Tomar una idea y llevarla, durante horas, días o semanas, hasta convertirla en algo que realmente funcione en el mundo real, sigue tomando lo mismo de siempre: tiempo, paciencia, curiosidad, criterio para iterar y tolerancia a equivocarse en el camino.

La IA reduce enormemente el esfuerzo necesario para llegar al primer borrador. Pero sigue existiendo una distancia entre "puedo hacerlo" y "lo hice funcionar". Esa distancia todavía no desaparece por el simple hecho de tener acceso a IA. Y mientras eso siga siendo así, seguirá siendo, precisamente, donde se construye una ventaja competitiva real.

En un mundo donde todos pueden preguntarle lo mismo a la misma IA, la diferencia ya no está en quién obtiene una respuesta. Está en quién sabe qué hacer con ella.

Tenemos IA, ¿dónde la usamos? — El error que hunde proyectos antes del primer modelo

2026-08-17T11:09:13.912-07:00

"Tenemos IA, ¿dónde la usamos?" — El error que hunde proyectos antes del primer modelo

Hay una pregunta que condena a un proyecto de IA antes de que nadie escriba una línea de código: "Tenemos esta herramienta, ¿dónde podemos usarla?"

Suena razonable. Alguien en la organización consiguió acceso a un modelo, una plataforma o una alianza con un proveedor, y ahora toca "encontrarle un caso de uso". El problema es que esa pregunta invierte el orden correcto. Empieza por la tecnología y busca después el problema, cuando debería ser exactamente al revés: ¿qué problema necesitamos resolver, qué resultado esperamos, y cómo sabremos si funcionó?

Esa diferencia —tool-first versus outcome-first— no es un matiz semántico. Es la línea que separa un prototipo llamativo de una solución que produce valor sostenido.

Por qué gestionar IA no es gestionar software

En un proyecto de software tradicional, los requisitos son relativamente estables y el camino hacia la entrega es lineal: se define, se construye, se prueba, se despliega. En IA, esa linealidad se rompe. Entran en juego la calidad y disponibilidad de los datos, la evaluación continua del modelo, el riesgo, la privacidad, la explicabilidad, la adopción por parte de los usuarios y el monitoreo posterior al despliegue. Un modelo que funciona hoy puede degradarse mañana si los datos que lo alimentan cambian. Un prototipo que impresiona en una demo puede no sobrevivir el contacto con datos reales, procesos reales y usuarios reales.

Esto obliga a pensar el proyecto en fases que se retroalimentan: entender el negocio, entender los datos, prepararlos, desarrollar el modelo, evaluarlo y llevarlo a operación. No como un checklist rígido, sino como un ciclo donde es normal —y necesario— regresar a una fase anterior cuando algo no cuadra. Retroceder no es fracaso. Es la metodología funcionando como debe.

El caso que lo explica mejor que cualquier framework

Una organización industrial quería "predecir fallas" en sus equipos de producción. Sonaba a proyecto de IA clásico: sensores, datos, modelo predictivo, alerta temprana. Pero al examinar el problema de negocio con más profundidad, apareció el dato que cambió todo: el equipo de mantenimiento no necesitaba predecir la falla en abstracto. Necesitaba siete días de anticipación, porque ese era el tiempo real que tomaba conseguir los repuestos.

Ese matiz —de "predecir fallas" a "avisar con siete días de margen"— redefinió por completo qué tenía que hacer el modelo y qué datos necesitaba para lograrlo.

Y ahí llegó el segundo hallazgo, más incómodo: los sensores registraban lecturas una vez por hora, mientras que ciertas fallas podían desarrollarse en cuestión de minutos. No importaba qué tan sofisticado fuera el modelo elegido; con esa granularidad de datos, la ventana de siete días de anticipación era, sencillamente, inalcanzable.

Ningún ajuste de hiperparámetros iba a resolver eso. El problema no estaba en el modelo. Estaba en cómo se había definido el objetivo y en si los datos disponibles podían siquiera sostenerlo. Un proyecto bien intencionado, con presupuesto y buena voluntad, puede irse contra un muro invisible si nadie hizo antes las preguntas incómodas.

Elegir el modelo, además, nunca es solo una cuestión de precisión. Entran en la ecuación el costo, la privacidad, la explicabilidad, el mantenimiento a futuro y la capacidad real de la organización para gobernar esa solución en el tiempo. Una opción técnicamente superior pero imposible de explicar a un regulador, o inviable de mantener con el equipo disponible, no es la mejor opción: es un riesgo disfrazado de innovación.

El rol del Project Manager cambia, no desaparece

El Project Manager de un proyecto de IA no necesita convertirse en Data Scientist. Pero sí necesita aprender a hacer las preguntas que antes daba por resueltas: ¿qué problema estamos resolviendo, realmente? ¿Qué significa éxito, en términos medibles? ¿Tenemos los datos adecuados, con la calidad y la frecuencia que el objetivo exige? ¿Qué margen de error es aceptable para este caso? ¿Cómo se va a evaluar el resultado antes de confiar en él? ¿Quién lo valida? ¿Cómo se va a operar y monitorear después del lanzamiento? ¿Está produciendo valor real, o solo funcionando?

Dicho de otra forma: el Project Manager de IA no necesita saber entrenar un modelo. Necesita saber reconocer cuándo el proyecto todavía no está listo para entrenarlo. Ese criterio —saber frenar a tiempo, o regresar una fase— vale más que cualquier certificación técnica, porque protege el presupuesto, la credibilidad del equipo y la confianza de quienes esperan resultados.

Muchos de los mayores obstáculos de un proyecto de IA no están en el algoritmo. Están en los datos, en la confianza que genera (o no) la solución, en la adopción real por parte de los usuarios, en el gobierno del proyecto y en procesos que no estaban pensados para convivir con un sistema que aprende y cambia.

La misma lógica aplica a lo pequeño

Este razonamiento no es exclusivo de proyectos industriales de gran escala. Aplica también a soluciones puntuales, como una herramienta de transcripción de audio.

La pregunta equivocada es "¿qué modelo de speech-to-text utilizamos?". La pregunta correcta es "¿qué necesita obtener realmente el usuario de esa grabación?". No es lo mismo transcribir una reunión para archivarla que transcribirla para extraer decisiones y tareas accionables. El objetivo define la herramienta, no al revés.

Con esa lógica nació ELISA Transcribe, pensada para convertir archivos de audio en contenido textual que pueda volver a utilizarse. El valor no está únicamente en pasar audio a texto: está en liberar información que antes quedaba atrapada dentro de una grabación y que nadie volvía a revisar. Hoy está disponible una prueba gratuita para audios de hasta 10 minutos, para quien quiera comprobar esa diferencia con un caso propio.

Al final, la pregunta que decide si un proyecto de IA prospera no es qué tan potente es el modelo disponible. Es si alguien se detuvo a preguntar, antes de tocar la tecnología, qué problema real se está resolviendo.

Referencia: Este artículo toma como punto de partida algunas ideas y casos presentados en el webinar de PMI “From Learning to Practice: Applying the CPMAI Methodology on Real-World AI Projects”. A partir de ellos desarrollo una reflexión propia sobre cómo abordar proyectos de IA desde el problema de negocio, los datos y la generación de valor.

Automatiza el patrón, no el juicio: dónde termina la IA y empieza el experto

2026-08-11T16:24:48.246-07:00

Automatiza el patrón, no el juicio: dónde termina la IA y empieza el experto

¿Qué parte del trabajo de un experto puede hacer una IA y qué parte debería permanecer en manos de una persona?

La respuesta no empieza escogiendo un modelo, una plataforma o una arquitectura. Empieza observando el trabajo humano.

Antes de construir un agente deberíamos ser capaces de responder preguntas mucho más simples: ¿qué hace hoy la persona?, ¿qué pasos repite?, ¿qué decisiones toma?, ¿qué excepciones enfrenta? y, sobre todo, ¿en qué momento deja de seguir un proceso y empieza a ejercer criterio?

Ahí aparece una distinción fundamental.

Una cosa es ejecutar un patrón. Otra muy distinta es ejercer juicio.

El patrón puede automatizarse. La excepción cambia el juego.

Gran parte de nuestro trabajo tiene patrones.

Recibimos información, la clasificamos, verificamos determinados datos, consultamos una fuente, generamos una respuesta y pasamos al siguiente paso.

Cuando ese flujo es suficientemente estable, la IA puede convertirse en una herramienta extraordinaria para acelerarlo.

El problema aparece cuando confundimos el proceso completo con sus partes repetitivas.

Pensemos en una aseguradora que utiliza un agente de IA para recopilar el primer reporte después de un accidente automovilístico.

Para un choque menor, el proceso puede funcionar perfectamente: ubicación, vehículo, fecha, daños, datos del asegurado.

Pero el escenario cambia radicalmente cuando el accidente incluye una muerte o una lesión grave.

La tecnología puede seguir haciendo las mismas preguntas. El formulario puede seguir necesitando los mismos datos. El workflow incluso puede ser técnicamente correcto.

Y, sin embargo, la solución deja de ser adecuada.

No porque la IA haya fallado.

Porque cambió el contexto.

La decisión inteligente no sería eliminar el agente, sino establecer una frontera: utilizar automatización para los casos rutinarios y transferir las situaciones sensibles o complejas a una persona.

Ese diseño tiene además un efecto interesante: al encargarse la IA de los casos repetitivos, el especialista recupera tiempo para aquellos donde su experiencia realmente importa.

El éxito no tiene que significar 100% de automatización

Existe una tentación frecuente en los proyectos de IA: considerar que automatizar una parte del proceso es insuficiente.

Si no llegamos al 100%, parece que algo salió mal.

Pero la realidad empresarial rara vez funciona así.

En un proyecto de onboarding internacional, por ejemplo, un mismo proceso podía automatizarse en determinados países donde las reglas y prácticas eran relativamente consistentes.

En otros, las diferencias locales hacían mucho más difícil establecer un único patrón.

¿Significa eso que el proyecto fracasó?

No necesariamente.

Si una solución consigue resolver de manera consistente una parte importante de los casos y permite que el equipo humano concentre su tiempo en las excepciones, puede estar generando exactamente el valor que necesitaba la organización.

Quizá la mejor pregunta no sea:

¿Cuánto conseguimos automatizar?

Sino:

¿Cuánto trabajo de poco valor eliminamos y cuánto tiempo devolvimos a las personas para resolver lo complejo?

El experto no desaparece: se reubica

Otro caso resulta especialmente interesante.

Una organización que trabajaba con programas educativos utilizó IA para apoyar a profesores que debían revisar numerosos ensayos.

El objetivo no fue entregar la decisión final al sistema.

La IA ayudaba a acelerar el análisis, mientras el profesor conservaba la evaluación y la responsabilidad final.

Una actividad que podía tomar aproximadamente tres horas se reducía a unos 45 minutos.

Nadie perdió autoridad.

Alguien recuperó tiempo.

Y esa diferencia es importante.

Cuando una herramienta permite que un experto dedique menos tiempo a clasificar, buscar, comparar o preparar información, no necesariamente disminuye su relevancia.

Puede ocurrir exactamente lo contrario.

El valor del especialista se desplaza hacia aquello que resulta más difícil de convertir en reglas: interpretar, contextualizar, cuestionar, decidir y asumir responsabilidad.

El riesgo de construir demasiado

También existe el problema contrario: enamorarnos de la solución tecnológica.

Un proyecto puede tener desarrollo personalizado, integración de datos, guardrails, modelos sofisticados y una experiencia cuidadosamente diseñada… y aun así no tener sentido económico.

Uno de los casos analizados involucraba un chatbot que permitía interactuar con una representación de una celebridad utilizando información previamente aprobada.

Funcionaba.

Las personas incluso conversaban durante largos periodos con el sistema.

Y precisamente allí apareció el problema: el consumo de tokens creció hasta un punto en que resultaba difícil justificar el retorno de inversión.

La tecnología hacía lo que se esperaba de ella.

El negocio no cerraba.

Esto debería recordarnos algo sencillo:

Una solución de IA no crea valor por ser técnicamente impresionante.

Crea valor cuando resuelve una fricción suficientemente importante a un costo razonable.

Lo que debería preguntar un Project Manager

Por eso, la primera conversación de un proyecto de IA no debería girar únicamente alrededor de arquitectura, proveedores o modelos.

Antes necesitamos entender el trabajo.

¿Qué proceso estamos intentando mejorar?

¿Qué patrón existe dentro de ese proceso?

¿Qué parte puede automatizarse de manera confiable?

¿Qué excepciones conocemos?

¿Qué ocurre cuando aparece una situación que no estaba prevista?

¿Cuándo debe intervenir una persona?

¿Quién mantiene la responsabilidad final?

¿Y qué métrica nos permitirá decir que la solución genera valor?

Responder esas preguntas exige que especialistas del negocio y especialistas tecnológicos trabajen juntos.

El desarrollador conoce lo que la tecnología puede hacer.

El experto conoce aquello que sucede cuando el proceso real deja de parecerse al diagrama.

Y el Project Manager tiene un papel fundamental conectando ambos mundos y evitando que el proyecto confunda una posibilidad tecnológica con una necesidad de negocio.

Human + AI

Probablemente, la conversación más productiva sobre inteligencia artificial no sea Human vs. AI.

Es Human + AI.

No se trata de proteger artificialmente cada tarea que hoy realiza una persona ni de automatizar todo simplemente porque podemos hacerlo.

Se trata de diseñar deliberadamente esa frontera.

Automatizar lo repetitivo.

Acelerar la búsqueda y el análisis.

Apoyar al experto.

Detectar las excepciones.

Y devolver la decisión a una persona cuando el contexto, el impacto o la responsabilidad así lo requieran.

Ideas que me llevo

El patrón se automatiza; el juicio se acompaña.
Una implementación de IA no necesita llegar al 100% para generar valor.
Las excepciones deberían diseñarse desde el inicio, no descubrirse cuando el sistema ya está en producción.
El ROI importa tanto como la capacidad técnica.
Liberar a un experto de tareas repetitivas puede aumentar, y no reducir, el valor de su experiencia.

La mejor IA quizá no sea la que consigue hacer todo sola.

Puede ser la que está diseñada para saber hasta dónde debe llegar.

Nota: Este artículo parte de ideas y casos compartidos por Joy Marie Curtis en el webinar “AI Beyond the Sales Pitch”, presentado para PMI. A partir de ellos desarrollo esta reflexión sobre gestión e implementación de soluciones de inteligencia artificial.

Si mañana tuvieras que incorporar un agente de IA en tu organización, ¿qué parte del trabajo automatizarías primero y qué decisión mantendrías necesariamente en manos de una persona?

Computer vision: la inteligencia artificial que convierte video en decisiones

2026-08-08T17:07:41.454-07:00

Computer vision: la inteligencia artificial que convierte video en decisiones

Hora punta en una estación de metro. El andén se llena, la gente se apretuja cerca de las puertas, y quien opera esa estación lo sabe exactamente igual que tú lo sabrías: mirando. "Hoy está más lleno que ayer." Nada más. Las cámaras están grabando ese andén en este preciso momento, y lo han grabado todos los días durante años. Pero ese video no le dice a nadie cuánta gente hay, a qué hora se satura de verdad, ni con qué frecuencia se cruza un límite peligroso. Solo lo graba. Lo archiva. Lo olvida.

Ese es el problema, y no es de cámaras. Es que toda esa información se queda dormida hasta que algo sale mal y alguien tiene que ir a buscarla. Computer vision —visión por computadora— es lo que rompe ese ciclo: un sistema que analiza el video mientras ocurre y devuelve un número donde antes solo había una sensación. Cuánta gente hay, dónde está, cómo cambia minuto a minuto. Modelos como YOLO ya hacen esto de forma madura y confiable. Pero el modelo es apenas el punto de partida. Lo que de verdad importa es lo que pasa después: qué se hace con ese dato.

Donde esto deja de ser un experimento y empieza a doler menos

Transporte. En una estación como la del ejemplo, tener la ocupación real por franja horaria cambia la conversación por completo. Ya no se refuerza personal "porque parece que se llena", se refuerza porque los datos muestran exactamente a qué hora y con qué frecuencia ocurre. La diferencia entre reaccionar y anticipar.

Banca. Una agencia, un lunes de fin de mes. La zona de espera se desborda y la organización se entera por la queja de un cliente en redes, o meses después, cuando llega la encuesta de satisfacción. Medir la ocupación real, franja por franja, convierte esa intuición del administrador de agencia en un dato que el área de operaciones puede llevar a un comité y defender frente a Riesgos, antes de que el problema aterrice en el NPS.

Gobierno. Una oficina de atención ciudadana con metas de servicio que cumplir y la presión constante de reducir tiempos de espera. Saber cuánta gente hay, cuándo se forman las colas más largas y cuánto tiempo se supera el nivel aceptable, le da a quien gestiona esa operación algo que hoy no tiene: evidencia auditable. Algo que sostener frente a un ente de control que no sea "la última queja que llegó".

El mismo principio se repite en retail y en salud. Cambia el escenario. No cambia lo esencial: convertir lo que ya se observa en algo que se puede medir.

Detectar no es el problema. Conectar sí lo es.

Aquí es donde la mayoría de conversaciones sobre IA se quedan cortas: detectar personas en un video es el paso fácil. El valor real aparece cuando esa detección se conecta con el resto de la operación —una regla de negocio, un tablero, una alerta— y alguien puede actuar sobre ella.

El sistema puede detectar treinta personas en una fila. Eso no lo convierte en quien decide qué hacer al respecto. Puede generar una alerta, sí. Pero actuar sobre esa alerta sigue siendo trabajo de alguien con nombre y cargo dentro de la organización. La tecnología acelera la información. La decisión sigue siendo humana, y así debería seguir siendo.

No se quedó en el papel

Todo esto suena razonable en una reunión. Yo preferí construirlo. Se llama ELISA Vision AI: toma un video real de una operación y lo convierte en señales que un gerente puede usar. Entiende cómo cambia la demanda en el tiempo, detecta picos por encima de umbrales configurables, y genera evidencia para evaluar capacidad y nivel de servicio.

Un punto que no puedo dejar pasar, sobre todo pensando en gobierno y salud: esta demo analiza ocupación visible. No identifica personas ni usa reconocimiento facial. Privacidad por diseño, no un parche agregado después.

ELISA Vision AI forma parte de Framework ELISA, donde vengo probando distintas formas de aplicar IA a problemas de negocio reales, siempre en el mismo orden: primero el problema, después la arquitectura, al final la tecnología específica.

ELISA Vision AI — prototipo funcional para análisis de ocupación mediante visión por computadora. Sin reconocimiento facial. La demostración pública está disponible en video.

La pregunta que de verdad importa

Ya no es qué tan sofisticado es un modelo de inteligencia artificial. Es qué decisión tomarías distinto si dejaras de operar a ojo y empezaras a operar con datos.

Si mientras leías esto pensaste en un proceso específico de tu organización, conversemos.

Gobernar la IA sin frenar la innovación: dónde debe intervenir el criterio humano

2026-08-06T16:04:57.818-07:00

Gobernar la IA sin frenar la innovación: dónde debe intervenir el criterio humano

Una empresa cualquiera. Marketing usa un asistente de IA para redactar campañas. Un gerente de operaciones prueba un copiloto para analizar reportes. Alguien graba sus reuniones con una herramienta de transcripción automática que ni siquiera pasó por un comité de seguridad. Nadie lo decidió formalmente. Simplemente ocurrió, mucho antes de que existiera una política corporativa capaz de darle sentido a todo esto.

Esta escena, con pequeñas variaciones, se repite en organizaciones de todos los tamaños. Y resume bastante bien el momento en el que estamos: la pregunta ya no es si debemos usar IA. La pregunta es cómo gobernarla sin frenar la innovación que ya está ocurriendo, con o sin permiso.

La adopción llegó antes que la gobernanza

Durante años la conversación sobre IA giró en torno a la posibilidad: qué tan capaz era, qué tan lejos podía llegar. Esa etapa ya pasó. Hoy prácticamente cualquier profesional ha usado alguna herramienta de IA generativa para resumir, analizar, redactar o planificar, muchas veces sin que su organización haya definido todavía reglas claras al respecto.

El problema no es la velocidad de adopción en sí. El problema es que las políticas, los procesos de revisión y los mecanismos de gobierno no avanzan al mismo ritmo. Las organizaciones más maduras en este terreno no empiezan preguntando qué herramienta de IA deberían implementar. Empiezan preguntando qué problema de negocio están tratando de resolver. Esa diferencia, aunque parezca sutil, es la que separa una adopción con propósito de una colección de experimentos sueltos sin dirección.

Human-in-the-loop (HITL) no puede ser un eslogan

Casi todas las organizaciones dirán que mantienen un humano en el ciclo de decisión. Pocas pueden explicar exactamente qué significa eso en su operación diaria. Y ahí está el problema: El concepto de human-in-the-loop suena bien en una diapositiva, pero si no se traduce en un modelo operativo real, es solo una frase tranquilizadora.

Un modelo operativo real responde preguntas concretas. Quién toma la decisión final. Quién revisa una recomendación generada por IA antes de que se convierta en acción. Qué datos puede consultar el sistema y cuáles quedan fuera de su alcance. Qué puntos del proceso requieren aprobación humana explícita, y no solo una revisión superficial. Cómo queda registrada esa decisión, de modo que exista trazabilidad si alguien necesita entender después por qué se hizo algo de determinada manera. Y cómo se monitorea el resultado con el tiempo, porque un modelo que funcionaba bien hace seis meses puede empezar a desviarse sin que nadie lo note.

Piensa en un comité de inversión que usa IA para priorizar un portafolio de proyectos. El sistema puede generar un mapa de calor con base en complejidad y probabilidad de éxito. Eso es información valiosa. Pero decidir cuáles iniciativas realmente merecen presupuesto sigue siendo una decisión humana, porque involucra contexto que el sistema no tiene: relaciones políticas internas, prioridades estratégicas no escritas, señales que un algoritmo simplemente no puede leer.

Aquí aparece un riesgo que vale la pena nombrar directamente: el sesgo de automatización. Es la tendencia a aceptar una recomendación solo porque la generó una IA, o porque el resultado suena convincente y está bien redactado. Ocurre con más frecuencia de la que nos gustaría admitir, entre profesionales experimentados que confían en un resultado fluido sin cuestionar si es correcto.

El riesgo silencioso: Shadow AI

Mientras las organizaciones definen sus políticas oficiales, algo distinto sucede en paralelo: los equipos ya están usando IA por su cuenta. Chats personales de IA generativa, copilotos instalados sin pasar por TI, asistentes de reuniones que graban y transcriben conversaciones enteras. Esto es lo que se conoce como Shadow AI, o "bring your own AI": herramientas que entran a la operación sin que Seguridad, Riesgos, TI o la PMO tengan visibilidad sobre qué información está saliendo de la organización ni hacia dónde.

Un caso frecuente: alguien activa un asistente de transcripción en una reunión donde se discuten cifras confidenciales o decisiones sensibles de personal, sin pensar en dónde queda almacenada esa grabación ni bajo qué términos de uso.

La respuesta natural sería prohibir. Pero prohibir sin ofrecer una alternativa solo empuja el uso más hacia la sombra. Un camino más realista empieza por inventariar qué herramientas ya se están usando en la práctica, sin actitud punitiva. Entender para qué las está usando la gente y qué necesidad real están cubriendo. Identificar qué tipo de datos procesan esas herramientas. A partir de ahí, establecer guardrails claros: qué se puede compartir con una IA externa y qué no. Y, quizás lo más efectivo, crear espacios controlados de experimentación, una especie de sandbox institucional donde los equipos puedan probar herramientas nuevas dentro de un marco seguro, en lugar de hacerlo por su cuenta.

La gobernanza no debe frenar la IA

Existe la idea de que gobernanza es sinónimo de burocracia, de poner trabas. Vale la pena replantear esa idea. La gobernanza bien diseñada no es una serie de obstáculos, es la estructura que permite que la organización se mueva rápido sin perder el control. La tensión real que toda organización tiene que administrar es entre velocidad y control, entre innovación y riesgo, entre automatización y responsabilidad humana. Ninguno de esos extremos gana solo; el trabajo está en equilibrarlos de forma consciente.

Y ese trabajo no puede aparecer al final del proyecto, como una revisión de cumplimiento de último minuto. La gobernanza tiene que diseñarse desde el momento en que se define el caso de uso: qué problema se quiere resolver, qué datos va a tocar, quién va a revisar sus resultados y bajo qué criterios se acepta, se rechaza o se escala una recomendación generada por el sistema. Cuando la gobernanza se piensa desde el inicio, deja de sentirse como un freno y empieza a funcionar como una guía.

Una reflexión final

El futuro no va a pertenecer a las organizaciones que simplemente usen más inteligencia artificial. Va a pertenecer a las que logren combinar IA, gobernanza y juicio humano de manera que produzcan mejores decisiones, no solo decisiones más rápidas. Esa combinación no aparece por accidente. Se diseña, se revisa y se ajusta constantemente. Gobernar la IA no significa controlar cada experimento: significa crear las condiciones para innovar sin perder de vista quién decide, con qué información y bajo qué responsabilidad.

La IA puede ayudarte a gestionar proyectos. Decidir por ti es otra cosa

2026-08-04T15:46:45.562-07:00

La IA puede ayudarte a gestionar proyectos. Decidir por ti es otra cosa

Hay una frase que escucho cada vez más en conversaciones con otros Project Managers: "le pedí a la IA que me resumiera el proyecto y salió algo genial". El problema no es que haya salido algo genial. El problema es cuando ese "algo genial" se convierte en la versión final que se envía al sponsor sin que nadie la revise. Ahí es donde la conversación sobre IA en gestión de proyectos deja de ser sobre productividad y empieza a ser sobre criterio profesional.

En los últimos meses he venido probando distintas herramientas de IA aplicadas al trabajo con tecnología y gestión de proyectos. Hace poco participé en un webinar de PMI dedicado justamente a este tema, y varias de las ideas que se plantearon conectaron con algo que considero fundamental: la IA puede acelerar el trabajo, pero no reemplaza a quien tiene que responder por las decisiones.

El verdadero problema no es la falta de información, es el exceso

Como PM, casi nunca te falta información. Te sobra. Actas de reunión, correos, logs de riesgo, cronogramas, feedback de stakeholders, actas de comité. El trabajo real está en encontrar qué de todo eso importa: qué decisión se tomó, qué riesgo quedó abierto, qué acción nadie cerró.

Ahí es donde la IA aporta valor real. No porque "sepa más" que tú, sino porque puede procesar volumen rápido y devolverte una estructura: decisiones, riesgos, acciones, inconsistencias. Si tienes tres actas de reunión con versiones distintas de un mismo acuerdo, pedirle a la IA que te señale las contradicciones es mucho más rápido que releer todo tú mismo. Pero eso es exactamente lo que le pides: que te ayude a ver mejor, no que decida por ti qué hacer con lo que encuentre.

Un mismo contenido, tres audiencias distintas

Otra cosa que cambia con IA bien usada es cómo comunicas. Tú trabajas desde una sola fuente de verdad —tu cronograma, tu registro de riesgos, tu backlog—, pero necesitas traducir eso para públicos distintos. Tu equipo necesita el detalle técnico. Tu sponsor necesita las decisiones clave y los riesgos que le afectan. Tu comité directivo probablemente solo necesita saber si el proyecto está en curso, en riesgo o detenido, y por qué.

Pedirle a la IA que tome el mismo contenido y lo adapte a cada audiencia es de los usos más prácticos que existen. El error típico es pedir "hazme un resumen para el sponsor" sin más contexto, y recibir algo genérico que cualquier PM de cualquier proyecto podría haber escrito. La diferencia está en decirle explícitamente para quién es, qué necesita saber esa persona, y en qué formato lo quieres. No es lo mismo pedir "resume esto" que pedir "escribe una actualización para mi comité directivo, de máximo 150 palabras, enfocada en los riesgos vigentes y las decisiones pendientes". El segundo prompt te da algo usable. El primero, casi nunca.

El contexto no es opcional, es lo que determina el resultado

Aquí hay algo que muchos PMs pasan por alto: la calidad de lo que recibes de la IA depende directamente de lo que le diste. Si le compartes documentación desactualizada, decisiones que ya cambiaron o información que solo existe en la cabeza de alguien del equipo, vas a recibir un output construido sobre esa base incompleta.

Esto no es un problema de prompting, es un problema de higiene de información. Mantener tu documentación de proyecto actualizada, con las decisiones realmente registradas y no solo comentadas de pasillo, es lo que hace que la IA trabaje con material confiable. Un espacio de trabajo con IA —una carpeta de proyecto, un asistente configurado con tus documentos— solo es tan bueno como lo que tú metes ahí. Y eso hay que revisarlo, no solo cargarlo una vez y olvidarlo.

Generar opciones no es lo mismo que asumir responsabilidad

La IA es útil para llegar más rápido a un primer borrador: un acta de kickoff, un plan de gestión de riesgos, un plan de involucramiento de stakeholders. Te saca de la hoja en blanco, que es donde más tiempo se pierde. También puede ayudarte a pensar: dale contexto sobre una situación difícil con un stakeholder y pídele que identifique qué se te puede estar pasando por alto. Funciona bien como un segundo par de ojos.

Pero ahí termina su rol. La IA no conoce la política interna de tu organización, no sabe qué batallas ya perdiste con ese sponsor, no entiende las implicancias reputacionales de una decisión. Puede darte opciones, escenarios, un borrador razonable. La responsabilidad de decidir qué es correcto para tu contexto sigue siendo tuya. Y esto se vuelve crítico cuando lo que está en juego es alcance, presupuesto, cumplimiento normativo o gobernanza: mientras más alto el riesgo, más estricta debe ser tu revisión antes de actuar sobre lo que la IA te entregó.

Cómo se ve el buen uso en la práctica

Un output de IA confiable no es el que suena mejor redactado. Es el que puedes verificar. Antes de compartir un resumen generado por IA con tu equipo o tus stakeholders, revisa al menos tres cosas: que las decisiones citadas sean correctas, que las fechas estén bien y completas, y que los riesgos mencionados realmente reflejen la situación actual. Un texto fluido y bien estructurado puede sonar convincente y aun así estar equivocado en un detalle que te cuesta caro después.

La reflexión que me llevo

Nadie discute ya si la IA ayuda en gestión de proyectos. Ayuda, y bastante. La pregunta que sí vale la pena hacerse es otra: ¿estoy usando esto para pensar mejor, o estoy dejando de pensar? La diferencia entre un PM que usa IA con criterio y uno que le delega el criterio no se nota en el primer proyecto. Se nota en el momento en que algo sale mal y tienes que explicar por qué tomaste esa decisión. Ahí no vale decir que lo dijo la IA. La firma, al final, sigue siendo tuya.

Referencias:

- Use AI to Level Up Your Project Work - Featuring Keriann Sabatini, and Cristina Olaru - July 22, 2026

Cuando el código ya no importa

2026-07-12T14:47:16.623-07:00

Cuando el código ya no importa

Durante décadas, la capacidad de transformar una idea en código fue una de las principales ventajas de un profesional de tecnología. Dominar la sintaxis, conocer las herramientas y construir una solución requería tiempo, experiencia y muchas horas de prueba.

Hoy, una inteligencia artificial puede generar en minutos una primera versión de lo que antes tomaba días: un script, una integración, una consulta compleja o un componente funcional.

Eso no significa que el código haya dejado de ser importante.

Significa que escribirlo ya no es suficiente para diferenciarse.

Cuando producir código se vuelve más rápido y accesible, el valor se desplaza hacia otras capacidades: comprender el problema, definir correctamente la solución, evaluar las alternativas, verificar lo generado y asumir la responsabilidad por el resultado.

El código puede aparecer en minutos.

El criterio para convertirlo en una solución real todavía necesita construirse.

Lo que antes tomaba semanas

Hasta hace poco, prototipar una idea requería tiempo considerable: investigar la tecnología adecuada, configurar el entorno, escribir el código base, depurar errores iniciales, iterar. Un profesional experimentado podía hacerlo en días. Uno en formación, en semanas.

Hoy, con herramientas de inteligencia artificial generativa, ese proceso se comprime. Un componente funcional, un script de integración, una consulta compleja a una base de datos, una función que antes requería documentación extensa y múltiples ciclos de prueba y error— todo eso puede generarse en minutos.

Esto no significa que el código generado sea perfecto, ni que cualquier persona pueda utilizarlo sin contexto. Significa que la barrera de entrada para producir código ha bajado de forma significativa. Y eso tiene consecuencias directas sobre dónde se concentra el valor profesional.

La IA reduce barreras, pero no reemplaza el conocimiento

Existe una confusión frecuente: creer que porque la IA puede generar código, el conocimiento técnico se vuelve opcional.

Es exactamente al revés.

Para utilizar correctamente lo que genera una IA se necesita entender la tecnología. Saber si el resultado es correcto. Identificar por qué falla. Evaluar si es seguro para producción. Estimar su impacto en rendimiento. Anticipar problemas de integración con sistemas existentes. Proyectar costos operativos. Considerar el mantenimiento a mediano plazo.

Un profesional sin base técnica puede obtener código que funciona en un entorno controlado y desplegarlo en producción sin notar que tiene una vulnerabilidad de seguridad, que ignora casos borde críticos o que generará problemas de escalabilidad al aumentar la carga. La IA entregó el componente. Nadie con el criterio necesario revisó lo que recibió.

El conocimiento técnico no desaparece. Se transforma en la capacidad de validar, cuestionar y decidir sobre lo que la IA produce.

El valor se desplaza: de escribir a definir y verificar

Si generar código se acelera, el cuello de botella se mueve hacia etapas cuya responsabilidad no puede delegarse por completo: entender qué se necesita construir, diseñar una arquitectura viable, integrar componentes en un sistema real y verificar que el resultado cumpla su propósito.

Esto implica habilidades que van más allá de la sintaxis. Implica comprensión del problema de negocio: ¿para qué existe este sistema, quién lo usa, cuáles son las restricciones reales? Implica criterio arquitectónico: ¿qué enfoque es más sostenible, cuál genera menos deuda técnica, cómo se relaciona esta decisión con el resto del ecosistema? Implica capacidad de verificación: ¿el resultado hace lo que debe hacer, bajo las condiciones en que debe hacerlo?

La velocidad para escribir código, por sí sola, deja de ser una ventaja suficiente. Un profesional capaz de definir con claridad lo que necesita construir, supervisar lo que la IA produce y asegurar que el resultado funciona en un entorno real, tiene un valor que no se replica fácilmente.

El perfil híbrido no reemplaza especialistas, los conecta

Esta transición favorece la consolidación de perfiles que conectan negocio, arquitectura, conocimiento técnico y ejecución. No porque una sola persona deba reemplazar a todos los especialistas de un equipo, sino porque el profesional que entiende cómo se relacionan sus decisiones con el resto del sistema — y con el problema que ese sistema intenta resolver — se convierte en un punto de articulación difícil de sustituir.

El arquitecto de soluciones que entiende el negocio. El gestor de producto que comprende las implicancias técnicas de sus decisiones. El analista de datos que comprende la infraestructura sobre la que trabaja. El especialista de campo que puede traducir una necesidad operativa en un requerimiento técnico preciso.

Estos perfiles híbridos no son nuevos. Pero el contexto actual los hace más relevantes, porque la IA amplifica su capacidad de ejecución porque les permite participar con mayor profundidad en la exploración, el diseño y la validación, sin reemplazar el trabajo especializado.

Las certificaciones siguen siendo valiosas, pero las evaluaciones deben evolucionar

Las certificaciones técnicas continúan teniendo sentido. Permiten conocer las capacidades, los conceptos y los límites de una tecnología. Facilitan un lenguaje común entre equipos. Señalan que alguien se ha expuesto de manera sistemática a un dominio.

Lo que debería evolucionar es la manera de evaluar ese conocimiento.

Lo que tiene más valor evaluar hoy es diferente: la capacidad de resolver un caso con las herramientas disponibles, de justificar una decisión arquitectónica, de identificar por qué una solución generada no es adecuada para un contexto particular. Criterio aplicado, no memoria aislada.

Las organizaciones cambian más despacio que la tecnología

Uno de los errores más comunes al analizar el impacto de la IA es esperar que las transformaciones ocurran de forma inmediata. Las herramientas cambian rápido. Las personas, los equipos y los procesos cambian más lentamente. Y esto no es una falla: es parte natural de cualquier ciclo de adopción tecnológica.

Incorporar IA en un flujo de trabajo no implica que ese flujo cambie de inmediato. Incorporar IA a una herramienta, un proceso o incluso al nombre de un rol no transforma automáticamente la forma de trabajo. La transición real ocurre de forma gradual, a medida que las prácticas se ajustan, los roles evolucionan y la manera de medir el desempeño se actualiza para reflejar lo que ahora tiene valor.

Reconocer este ritmo diferente es útil tanto para los profesionales que navegan el cambio como para las organizaciones que intentan gestionarlo.

Cuando generar código deja de ser lo más difícil

Hay una consecuencia que no suele mencionarse: cuando la parte técnica de producir código se vuelve más accesible, queda expuesto lo que siempre estuvo detrás de ella.

El criterio para decidir qué construir y qué no. La capacidad de diseñar una solución que sea sostenible, no solo funcional. La habilidad de anticipar consecuencias: en seguridad, en costos, en operación, en la experiencia de quien usa el sistema. La responsabilidad de verificar que lo entregado resuelve el problema real, no solo el problema definido en el prompt.

La IA es un acelerador extraordinario. Reduce el tiempo de exploración, facilita la experimentación y amplía el acceso a capacidades técnicas. Pero lo que finalmente se despliega, opera e impacta en personas reales continúa requiriendo conocimiento, validación y responsabilidad humana.

Cuando generar código deja de ser la parte más difícil, el valor no desaparece: se desplaza hacia la capacidad de definir correctamente el problema, diseñar una solución sostenible y responder por sus resultados.

Porque el código puede generarse. El criterio para convertirlo en una solución todavía debe construirse.

¿Qué habilidad crees que gana más valor cuando la IA acelera la producción de código? La conversación está abierta en los comentarios.

Cuando medir el trabajo compite con el trabajo

2026-07-06T17:33:26.026-07:00

Cuando medir el trabajo compite con el trabajo

El peso invisible de registrar lo que ya hiciste

Hay una paradoja que vive silenciosa en muchas organizaciones modernas: el profesional que más produce es, con frecuencia, el que menos tiempo tiene para reportar lo que produjo.

No es un problema nuevo. Pero sí es uno que ha crecido junto con la digitalización. A medida que las empresas adoptaron plataformas de gestión —CRM, herramientas de seguimiento de proyectos, sistemas de registro de riesgos, formularios de horas trabajadas— también introdujeron, sin quererlo, una carga paralela de trabajo que no genera valor directo pero consume tiempo real.

La pregunta que vale la pena hacerse es: ¿en qué punto el acto de medir el trabajo empieza a competir con el trabajo mismo?

El vendedor que vende menos porque tiene que reportar que vendió

Imaginemos a un ejecutivo comercial. Su función principal es relacionarse con clientes, identificar oportunidades y cerrar negocios. Sin embargo, al final de cada jornada —o peor, en medio de ella— debe abrir el CRM corporativo y registrar cada llamada, cada reunión, cada avance en el pipeline. Campos obligatorios, categorías predefinidas, comentarios que debe redactar con suficiente detalle para que su jefe entienda el contexto.

Lo mismo ocurre con el especialista de campo, el gestor de proyectos o el analista de riesgos. Profesionales cuyo valor está en la ejecución, el criterio y la relación con los stakeholders, que deben destinar parte de su energía cognitiva a convertirse, temporalmente, en operadores de data entry.

Este fenómeno puede entenderse como una forma de carga administrativa no productiva. Y aunque parece un detalle operativo menor, sus efectos acumulados son significativos: desconcentración, pérdida de momentum, duplicación de esfuerzos y, en muchos casos, registros incompletos o poco fiables porque el profesional los completa a destiempo, de memoria o con prisa.

La lógica detrás del formulario

Para ser justos, la intención original de estos sistemas no es equivocada. Las organizaciones necesitan trazabilidad. Los líderes necesitan visibilidad sobre el avance de sus equipos. Los sistemas de riesgo necesitan datos para anticipar problemas. Y la información estructurada permite tomar mejores decisiones.

El problema no está en querer medir. El problema está en cómo se mide y quién asume el costo de ese registro.

En muchos casos, la decisión de implementar un sistema de seguimiento se toma desde una perspectiva gerencial o tecnológica, sin considerar el impacto en la productividad operativa del equipo. Se escoge la plataforma, se definen los campos, se capacita al equipo en el uso de la herramienta y se establece su uso como obligatorio. El resultado: el sistema existe, los datos se registran (con mayor o menor fidelidad), y el equipo siente que una parte de su jornada se fue en alimentar una base de datos en lugar de hacer su trabajo.

Tecnología que avanza, procesos que no

Aquí es donde aparece una brecha que merece atención. En los últimos años, el ecosistema de herramientas para la gestión del trabajo ha evolucionado considerablemente. Plataformas modernas integran dashboards automáticos, seguimiento por KPIs, alertas inteligentes e incluso análisis predictivo. Algunas ya incorporan inteligencia artificial para generar resúmenes, detectar patrones o sugerir próximos pasos.

En teoría, estas herramientas deberían reducir la fricción del registro. Y en muchos casos lo hacen. Pero la brecha no siempre está en la tecnología: está en el modelo mental con el que se gestiona.

Si la cultura organizacional sigue exigiendo que el profesional llene formularios manualmente, que justifique cada hora de su jornada o que replique información que ya existe en otro sistema, ninguna plataforma sofisticada resuelve el problema de fondo. La tecnología actualiza la herramienta, pero no necesariamente el proceso ni la filosofía de gestión detrás de él.

La adopción tecnológica sin rediseño de procesos es, con frecuencia, automatizar la ineficiencia.

El potencial sin explotar de la automatización inteligente

La buena noticia es que existen caminos concretos para cerrar esta brecha. Y muchos de ellos ya son técnicamente viables con las herramientas disponibles hoy.

Captura automática desde fuentes existentes. Si un profesional ya registra su trabajo en correos, calendarios, chats o documentos compartidos, gran parte de esa información puede extraerse y estructurarse automáticamente. No tiene sentido pedirle que lo vuelva a escribir en otro sistema.

Consolidación masiva desde archivos de trabajo. En lugar de ingresar datos uno por uno en una plataforma, es posible diseñar flujos que tomen un archivo estructurado —una hoja de cálculo, un reporte semanal— y alimenten automáticamente el sistema de gestión. Este enfoque reduce el tiempo de registro de horas a minutos y elimina el error de transcripción.

Asistentes de IA para el registro contextual. Herramientas actuales permiten que un profesional describa verbalmente lo que hizo en una reunión o en una visita de campo, y que esa descripción se convierta automáticamente en un registro estructurado en el sistema correspondiente. No es ciencia ficción: es una aplicación directa de los modelos de lenguaje disponibles hoy.

Dashboards que se alimentan automáticamente. Cuando los datos fluyen desde el trabajo real —integraciones con calendarios, seguimiento de correos, conexión con sistemas operacionales o transaccionales— el dashboard deja de ser un destino al que hay que alimentar manualmente y se convierte en una vista en tiempo real del trabajo que ya está ocurriendo.

El punto común de todos estos enfoques es el mismo: el registro debe ser una consecuencia del trabajo, no una tarea adicional sobre él.

Lo que las organizaciones pueden hacer distinto

Más allá de la tecnología, hay decisiones de gestión que marcan la diferencia entre un sistema de seguimiento que suma y uno que resta.

Auditar la carga de registro antes de implementar. Antes de exigir que un equipo adopte una nueva plataforma, vale la pena medir cuánto tiempo tomará completar los registros requeridos por semana. Como criterio interno de evaluación, una organización podría revisar el diseño cuando la carga de registro supera el 10% de la jornada.

Distinguir entre datos que informan y datos que controlan. No toda la información que se puede pedir es información que se necesita. Un buen diseño de sistema parte de la pregunta: ¿qué decisiones vamos a tomar con este dato? Si no hay una respuesta clara, ese campo probablemente sobra.

Involucrar al equipo operativo en el diseño. Los que mejor saben qué información es útil y qué es ruido son quienes ejecutan el trabajo. Incluirlos en el diseño de los sistemas de seguimiento no solo mejora la calidad del dato: también aumenta la adopción.

Medir la carga, no solo el cumplimiento. Un equipo que llena todos los formularios no es necesariamente un equipo productivo. Puede ser un equipo que aprendió a cumplir con el reporte a costa de otras prioridades. Los líderes que entienden esto complementan sus métricas de registro con métricas de resultado real.

Un cambio de perspectiva necesario

El debate sobre cómo medir el trabajo no es nuevo, pero la inteligencia artificial y la automatización lo ponen en un momento de inflexión. Hoy es técnicamente posible diseñar sistemas donde el profesional trabaja y el registro ocurre como consecuencia natural de ese trabajo, sin fricción adicional.

Lo que hace falta, en muchas organizaciones, no es más tecnología. Es una revisión honesta del modelo de gestión: ¿estamos midiendo para tomar mejores decisiones, o estamos midiendo porque siempre lo hemos hecho así?

Los equipos más efectivos de los próximos años no serán los que más reportan. Serán los que han logrado que reportar y trabajar sean, en la práctica, la misma cosa.

¿Tu organización ha logrado integrar el registro en el flujo de trabajo, o el formulario sigue siendo la tarea después de la tarea? La conversación empieza en los comentarios.

Alucinaciones en IA: por qué el contexto sí importa

2026-07-02T14:47:21.764-07:00

Alucinaciones en IA: por qué el contexto sí importa

Construí un agente conversacional. Lo llamé ELISA 101.

Lo alimenté con mis propios artículos y documentación que yo misma había curado. Lo probé durante semanas. Funcionaba bien... hasta que un día me respondió citando una norma ISO que no existe.

No era un error menor. Era una afirmación técnica, con número de norma incluida, presentada con total seguridad. Si eso hubiera ocurrido en un banco, en una consulta regulatoria, o en una decisión de crédito, las consecuencias podrían haber sido serias.

Ese día entendí algo que cambió mi forma de ver la inteligencia artificial:

La confiabilidad de una solución de IA no depende únicamente del modelo. Depende también de las instrucciones, los controles y, sobre todo, del contexto que ponemos a su disposición.

¿Qué es el contexto en una solución de IA?

Cuando una empresa implementa un asistente de IA, ese asistente no trabaja solo con lo que "aprendió" durante su entrenamiento. También trabaja con información que le proporcionamos nosotros: documentos internos, políticas, bases de conocimiento, manuales, reportes.

Eso es el contexto: la información que le damos al modelo para que responda sobre nuestra realidad específica.

Y aquí está el punto crítico que muchos pasan por alto:

Un modelo brillante con contexto deficiente produce respuestas deficientes. Un modelo modesto con contexto de calidad produce respuestas confiables.

El modelo es el motor. El contexto es el combustible. Y con combustible contaminado, el mejor motor del mundo falla.

Por qué ocurren las alucinaciones

Las alucinaciones en IA no son bugs aleatorios. Tienen causas concretas:

El modelo no encuentra la respuesta en el contexto que le dimos, y en lugar de decir "no sé", completa con su conocimiento general de entrenamiento. Eso fue exactamente lo que pasó con mi ISO inexistente: la información precisa no estaba en mis documentos, y el modelo "inventó" una respuesta plausible.

Otras causas frecuentes son contexto desactualizado, fuentes contradictorias entre sí, o información mal estructurada que confunde al modelo al momento de recuperarla.

En entornos personales o experimentales, una alucinación es una anécdota. En un banco, una aseguradora o una empresa regulada, puede ser un riesgo real.

5 formas de reducir las alucinaciones en la práctica

No existen fórmulas mágicas para eliminar por completo las alucinaciones, pero sí controles que pueden reducirlas de manera significativa. Estas son cinco estrategias que cualquier líder que supervise una solución de IA debería conocer:

1. Grounding estricto

Se le indica al modelo que responda únicamente con la información disponible en el contexto proporcionado. Si no encuentra evidencia suficiente, debe reconocerlo en lugar de completar la respuesta con su conocimiento general.

Esta instrucción no garantiza por sí sola que el modelo nunca se equivoque, pero establece un límite claro: es preferible un “no tengo información suficiente” a una respuesta convincente, pero inventada.

2. Umbral de relevancia

Antes de generar una respuesta, el sistema evalúa qué tan relacionada está la información recuperada con la pregunta del usuario.

Si los documentos encontrados no superan el nivel mínimo de relevancia definido, el sistema puede abstenerse de responder y devolver un mensaje de información insuficiente.

Este puntaje no demuestra que una respuesta sea correcta, pero ayuda a evitar que el modelo responda utilizando fragmentos poco relacionados con la consulta.

3. Citación y verificación de fuentes

El modelo debe indicar de qué documento o sección obtuvo la información utilizada en su respuesta.

Sin embargo, no basta con mostrar una referencia: también es necesario comprobar que la fuente citada respalde realmente la afirmación.

En entornos regulados, esta trazabilidad es fundamental.

Si no puede citar una fuente válida, no debería afirmar.

4. Validación posterior a la generación

Una vez generada la respuesta, un segundo proceso puede contrastarla con el contexto original para detectar afirmaciones que no tengan respaldo.

Una de las técnicas utilizadas para ello es LLM-as-a-judge, en la que otro modelo revisa la respuesta y evalúa si es coherente con las fuentes disponibles.

Este mecanismo tampoco es infalible, por lo que, en decisiones sensibles, debe complementarse con reglas automáticas y validación humana.

5. Gobierno de la base de conocimiento

Este es uno de los controles más importantes y, a la vez, uno de los más ignorados.

Ninguna estrategia funcionará correctamente si la base de conocimiento contiene información desactualizada, duplicada, contradictoria o mal estructurada.

Cada fuente debería tener un responsable, una versión oficial, una fecha de actualización y criterios claros de validación.

Sin gobierno del contexto, no hay IA confiable.

Lo que aprendí

Construir ELISA 101 fue una de las experiencias más reveladoras de mi carrera técnica. No porque el agente fuera perfecto, sino precisamente porque no lo era.

Me enseñó que implementar IA generativa en una organización no consiste únicamente en elegir el modelo correcto. También exige gestionar el conocimiento, asegurar la calidad de la información y establecer controles claros sobre las fuentes que alimentan la solución.

Las empresas que entiendan esto primero tendrán una ventaja real. Las que crean que basta con “instalar un chatbot” probablemente aprenderán la lección de la manera difícil.

El contexto sí importa. Mucho más de lo que parece.

¿Tu organización ya está pensando en cómo gestionar el contexto de sus soluciones de IA? Déjame tu comentario.

El Arquitecto de Soluciones como puente entre el negocio y la tecnología

2026-06-29T20:46:25.044-07:00

El Arquitecto de Soluciones como puente entre el negocio y la tecnología

La mayoría cree que un arquitecto elige tecnología. Ese es el error.

Hay un perfil que existe en casi todas las organizaciones de tecnología, aunque no siempre tiene ese nombre en la tarjeta de presentación.

Es el que se sienta con el área comercial a entender qué necesitan realmente. Luego se sienta con el equipo técnico a entender qué es viable. Y en el medio — en ese espacio incómodo donde el negocio habla un idioma y la tecnología habla otro — construye el puente.

A veces ese perfil se llama Tech Lead. A veces Analista Funcional Senior. A veces Project Manager con mucho criterio técnico. Y a veces, cuando la organización tiene el cargo formalizado, se llama Arquitecto de Soluciones.

Pero el título no lo define. Lo define la forma de pensar.

El error más común: confundir arquitectura con tecnología

Cuando alguien dice "vamos a necesitar un arquitecto para este proyecto", muchos equipos entienden: "alguien que elija qué tecnologías usar". AWS o Azure. Microservicios o monolito. Kafka o RabbitMQ.

Ese es exactamente el error.

Un Arquitecto de Soluciones no empieza eligiendo tecnologías. Empieza haciendo preguntas incómodas:

¿Qué problema de negocio estamos resolviendo realmente?
¿Qué pasa si no lo resolvemos?
¿Con qué sistemas existentes tiene que convivir esta solución?
¿Cuáles son las restricciones reales — regulatorias, presupuestarias, de tiempo?
¿Qué riesgos estamos asumiendo con cada decisión?

La tecnología viene al final. Siempre. Y esa secuencia — primero el negocio, luego la arquitectura, luego la tecnología — es la que separa una solución bien diseñada de una que genera deuda técnica, retrabajo y proyectos que nadie recuerda con orgullo.

El puente que nadie ve — hasta que se cae

En los proyectos tecnológicos existe una brecha que aparece una y otra vez, en banca, en telecomunicaciones, en gobierno, en salud. La brecha entre lo que el negocio quiere y lo que el equipo técnico entiende que debe construir.

El negocio habla de "mejorar la experiencia del cliente en el onboarding digital". El equipo técnico escucha "hay que cambiar el formulario de registro". Y así, sin que nadie lo note, el proyecto se construye sobre un malentendido.

Meses después, el producto entregado no resuelve el problema original. El negocio queda insatisfecho. El equipo técnico queda frustrado porque — desde su perspectiva — hicieron todo lo que les pidieron.

Los dos tienen razón. Y los dos perdieron.

El Arquitecto de Soluciones es el profesional cuyo trabajo es evitar exactamente eso. No solo una vez al inicio del proyecto — sino durante todo el ciclo de vida. Traduciendo, validando, cuestionando, facilitando. Asegurándose de que lo que se construye resuelve el problema que originó el proyecto, no el problema que alguien describió mal en una reunión de kick-off.

Los cuatro dominios que toda solución debe considerar

En organizaciones complejas — y la banca es el ejemplo más exigente — una solución bien diseñada debe navegar cuatro dimensiones que rara vez se alinean solas:

Negocio: ¿qué capacidad nueva o mejorada habilita esta solución? ¿Cómo se mide el éxito? ¿Quién es el dueño del proceso?

Datos: ¿qué información necesita fluir, entre qué sistemas, con qué frecuencia y con qué nivel de consistencia? ¿Dónde vive el dato maestro? ¿Quién es responsable de su calidad?

Aplicaciones: ¿qué sistemas están involucrados? ¿Cuáles se reutilizan, cuáles se modifican, cuáles son nuevos? ¿Cómo se integran entre sí?

Tecnología: ¿qué infraestructura, plataformas y herramientas soportan todo lo anterior de manera segura, escalable y sostenible?

Frameworks como TOGAF formalizan esta secuencia. BIAN, en el mundo bancario específicamente, va un paso más allá: define un lenguaje común de capacidades — Customer Onboarding, Payments, Risk & Compliance, Channels — que permite que equipos de distintas organizaciones, países y tecnologías hablen exactamente el mismo idioma.

Lo interesante de estos marcos no es la metodología en sí. Es la disciplina que imponen: no puedes diseñar la solución tecnológica si primero no entiendes el dominio de negocio. No puedes definir las integraciones si no tienes claro el modelo de datos. No puedes elegir la infraestructura si no sabes qué aplicaciones vas a correr.

El orden importa más de lo que parece.

Microservicios, EDA, API Gateway — cuándo importan y cuándo no

Hay un momento en casi toda conversación de arquitectura en que alguien dice "hagámoslo con microservicios" o "necesitamos event-driven". Y la pregunta correcta no es si esas son buenas ideas — generalmente lo son. La pregunta correcta es: ¿para qué problema específico?

Un monolito bien diseñado puede ser exactamente la solución correcta para un sistema interno de baja criticidad. Tiene menos complejidad operativa, es más fácil de desarrollar con equipos pequeños y más simple de debuggear. Elegir microservicios en ese contexto no es modernidad — es sobreingeniería.

En cambio, cuando una transferencia bancaria necesita disparar simultáneamente un registro contable, una notificación al cliente, un análisis antifraude y una actualización del historial crediticio — sin que el fallo de cualquiera de esos procesos detenga a los demás — una arquitectura orientada a eventos con un broker como Kafka no es un lujo. Es la única forma razonable de hacerlo.

La elección correcta siempre depende del contexto: el volumen de transacciones, la madurez del equipo, las restricciones regulatorias, el presupuesto disponible, los sistemas existentes con los que hay que integrarse.

Un arquitecto que llega a cada proyecto con la misma solución, independientemente del contexto, no está haciendo arquitectura — está aplicando una plantilla.

La pregunta que más revelan las entrevistas de arquitectura

"¿Cómo diseñarías una solución para X?"

Es la pregunta clásica. Y la respuesta incorrecta — la que más candidatos dan — es empezar a hablar de tecnologías. "Usaría AWS Lambda para el procesamiento, DynamoDB para el storage, API Gateway para la exposición..."

La respuesta que marca la diferencia empieza así: "¿Puedo hacerte algunas preguntas primero?"

¿Qué problema de negocio resuelve X? ¿Cuántos usuarios concurrentes esperamos? ¿Existen sistemas legados con los que debe integrarse? ¿Cuáles son los requisitos regulatorios? ¿Cuál es el presupuesto? ¿En qué plazo debe estar operativo?

Solo después de responder esas preguntas tiene sentido hablar de tecnologías. Y normalmente, la solución óptima no es la más sofisticada — es la que resuelve el problema real con la menor complejidad sostenible.

Eso es arquitectura.

El perfil que más escasea: quien habla los dos idiomas

Lo que hace al Arquitecto de Soluciones un rol genuinamente difícil de cubrir no es el conocimiento técnico — hay muchos profesionales con sólidos conocimientos en cloud, APIs, bases de datos, patrones de integración.

Lo difícil es encontrar a alguien que pueda sentarse con un gerente comercial y entender lo que realmente necesita. Que pueda luego sentarse con el equipo de desarrollo y traducir esa necesidad en especificaciones técnicas concretas. Que pueda presentar ante un comité ejecutivo las alternativas evaluadas con sus trade-offs, sin asumir que todos saben qué es un circuit breaker o un consumer group de Kafka. Y que pueda, al mismo tiempo, defender esas decisiones técnicamente ante un equipo de arquitectos.

Esa capacidad de navegar fluidamente entre el lenguaje del negocio y el lenguaje de la tecnología — sin perder precisión en ninguno de los dos — es lo que hace que este rol sea estratégico en cualquier organización que dependa de la tecnología para crecer.

Y en 2025, eso es prácticamente todas.

Reflexión final: el título no hace al arquitecto

Existen Arquitectos de Soluciones que en la práctica solo eligen tecnologías y diagraman en Lucidchart. Y existen Project Managers, Tech Leads y Analistas funcionales que hacen arquitectura todos los días sin ese título en su tarjeta.

Lo que define al Arquitecto de Soluciones no es el nombre del cargo. Es la forma de pensar: siempre empezando por el problema de negocio, siempre evaluando alternativas con sus trade-offs, siempre considerando el impacto en los sistemas existentes, siempre pensando en la sostenibilidad de la solución a largo plazo.

Si esa es tu forma de trabajar — si llevas tiempo siendo ese puente entre lo que el negocio necesita y lo que la tecnología puede hacer — entonces ya piensas como un arquitecto.

El título puede venir después.

¿Te identificas con este perfil aunque no tengas ese cargo? ¿O conoces organizaciones donde el arquitecto diseña en el vacío, sin conectar con el negocio? Me interesa leer tu perspectiva en los comentarios.

En próximos posts: qué significa liderar el contexto de un equipo de tecnología — y por qué puede ser más valioso que liderar el código. Y también: cuándo medir el trabajo empieza a competir con hacer el trabajo.

¿Qué tan difícil es llevar un proyecto de implementación de CRM?

2026-06-18T16:44:56.055-07:00

¿Qué tan difícil es llevar un proyecto de implementación de CRM?

En muchos proyectos tecnológicos, la complejidad suele medirse por la plataforma, las integraciones, la arquitectura o el nivel de personalización requerido.

Pero cuando hablamos de implementar un CRM, esa mirada se queda corta.

Un CRM no es solo una herramienta para registrar clientes, oportunidades o actividades comerciales. Es una forma distinta de ordenar la relación entre la empresa y sus clientes. Y eso significa tocar procesos, hábitos, métricas, reportes, responsabilidades y, sobre todo, comportamientos.

Por eso, la pregunta no debería ser únicamente: “¿Qué tan difícil es implementar un CRM?”

La pregunta más importante es: ¿qué tan preparada está la organización para cambiar la forma en que trabaja con sus clientes?

Después de varios años liderando proyectos tecnológicos, he llegado a una conclusión clara: la dificultad real de un CRM no está solo en la tecnología. Está en lograr que la herramienta se convierta en parte viva del negocio.

El mito de la complejidad técnica

Cuando alguien escucha "implementación de CRM", suele imaginarse arquitecturas intrincadas, integraciones imposibles y noches sin dormir depurando código. Y sí, hay complejidad técnica — no voy a negarlo.

Los retos más comunes en la capa técnica suelen ser tres:

Las integraciones con sistemas legados. Si la empresa tiene un ERP de hace quince años, un sistema de facturación desarrollado a medida o plataformas de terceros con APIs poco documentadas, la integración puede volverse un laberinto. Los datos están en formatos distintos, los catálogos no coinciden, y a veces hay procesos de negocio que nadie documentó porque "siempre se hizo así".

La arquitectura híbrida nube / on-premise. Cuando parte de la solución vive en la nube y otra parte en los servidores locales de la empresa, aparecen latencias que no estaban contempladas en el caso de negocio original. Una sincronización que en el papel debería tomar milisegundos, en producción puede tardarse segundos — y eso tiene impacto real en la experiencia del usuario.

Las particularidades del fabricante. Cada plataforma CRM tiene su lógica, sus limitaciones y sus peculiaridades. Pero aquí viene algo importante: cuando encuentras un problema técnico con el producto, puedes preguntar al fabricante. Hay documentación, hay soporte, hay comunidades. Los problemas técnicos, aunque incómodos, tienen caminos conocidos para resolverse.

En resumen: la complejidad técnica es real, pero es aterrizable.

El verdadero reto: la adopción

Ahora viene lo que realmente define el éxito o el fracaso de un proyecto CRM, y es algo que muchos líderes técnicos subestiman hasta que lo viven en carne propia.

El mayor reto de un CRM no es implementarlo. Es que la gente lo use.

Puedes tener la plataforma perfectamente configurada, las integraciones funcionando sin errores, los dashboards impecables, el rendimiento optimizado — y el proyecto puede fracasar igualmente si los equipos comerciales, de servicio o de marketing no adoptan la herramienta en su trabajo diario.

¿Por qué ocurre esto?

Primero, porque un CRM cambia la forma en que las personas trabajan. Y el ser humano, por naturaleza, resiste el cambio. Un vendedor que llevaba diez años gestionando sus contactos en una hoja de Excel, en correos sueltos o simplemente en su memoria, ahora tiene que registrar cada interacción, actualizar etapas del pipeline, documentar acuerdos y mantener información visible para otros equipos.

Si no entiende el por qué detrás de eso, lo percibirá como una carga administrativa, no como una herramienta que le ayuda a vender más, atender mejor o tomar mejores decisiones.

Segundo, porque la adopción es el único indicador que realmente confirma si el CRM está generando valor. No importa cuántas funcionalidades tenga la plataforma si solo una parte del equipo la usa de forma consistente. Los datos estarán incompletos, los reportes serán inexactos y la dirección no podrá tomar decisiones basadas en información confiable.

El sistema existirá, pero no vivirá.

Cómo se gestiona realmente la adopción

La adopción no se gestiona en la última semana antes del go-live con una capacitación de dos horas. Se construye desde el inicio del proyecto.

Algunas prácticas que marcan la diferencia:

Involucrar a los usuarios desde el diseño. Las personas adoptan mejor lo que sienten cercano a su realidad. Si el equipo comercial participa en definir qué campos son necesarios, qué reportes necesita ver y cómo se integra el CRM a su flujo de trabajo diario, la resistencia durante la implementación será mucho menor.

Demostrar valor temprano. Una de las estrategias más poderosas es mostrar a los usuarios que el CRM les facilita la vida a ellos, no solo al management. Si un vendedor ve que puede acceder al historial completo de un cliente en segundos antes de una llamada, sin buscar en correos o preguntar a un colega, empieza a entender el valor de manera concreta.

Diseñar la gobernanza de datos desde el principio. ¿Quién es responsable de mantener actualizada la información de los clientes? ¿Qué pasa cuando un dato está desactualizado? ¿Qué campos son obligatorios y cuáles solo generan ruido? Si no hay reglas claras sobre cómo se gestiona la información en el CRM, la calidad de los datos se degrada rápidamente y el sistema pierde utilidad.

Medir la adopción como KPI del proyecto. Tan importante como el número de errores técnicos o el tiempo de respuesta del sistema, es saber cuántos usuarios están activos, con qué frecuencia ingresan, qué módulos utilizan y qué información registran. Eso te dice si el proyecto está funcionando de verdad.

El patrocinio ejecutivo no es un lujo, es una condición

Existe otro factor que puede hacer o deshacer la adopción: el apoyo visible de la dirección.

Cuando el CEO, el Director Comercial o el VP de Ventas usan el CRM, lo mencionan en las reuniones y piden reportes basados en él, el mensaje que llega al equipo es inequívoco: esto es importante, esto es cómo trabajamos aquí.

Cuando ese patrocinio es tibio o inexistente — "implementen el CRM, pero yo no tengo tiempo para eso" — el proyecto pierde fuerza independientemente de qué tan buena sea la tecnología.

He visto proyectos con plataformas limitadas avanzar bien por el compromiso del equipo directivo, y proyectos con herramientas robustas perder impacto por falta de liderazgo, claridad y seguimiento.

Porque en una implementación de CRM, el patrocinio ejecutivo no sirve solo para aprobar presupuesto. Sirve para legitimar el cambio.

Entonces, ¿es difícil implementar un CRM?

Sí. Pero no por las razones que muchos piensan.

La tecnología tiene soluciones. Los bugs tienen fixes. Las integraciones tienen arquitecturas. Los problemas técnicos, por complejos que sean, tienen un camino lógico para resolverse.

Lo que no tiene solución puramente técnica es la resistencia humana al cambio, la falta de claridad sobre cómo la herramienta sirve a los usuarios y la ausencia de liderazgo que guíe la transformación.

Un proyecto de implementación de CRM exitoso es, en el fondo, un proyecto de gestión del cambio organizacional que incluye tecnología — no al revés.

Y eso, en mi experiencia liderando proyectos tecnológicos, aplica para casi cualquier sistema empresarial que se quiera implementar. El CRM no es la excepción. Es el ejemplo perfecto de una verdad que la industria tecnológica sigue aprendiendo:

La tecnología es el medio. Las personas son el fin.

¿Has liderado o participado en una implementación de CRM? ¿Cuál fue el mayor reto que enfrentaste? Me encantaría leer tu experiencia en los comentarios.

La Paradoja de los Datos

2026-06-08T09:13:59.942-07:00

La Paradoja de los Datos

¿Por qué fracasan los proyectos de datos aunque la tecnología funcione perfectamente?

La respuesta lleva décadas frente a nosotros y seguimos ignorándola.

Cada ciclo tecnológico trae una promesa nueva. Llegaron los Data Warehouses. Luego los Data Lakes. Después Big Data. Hoy, Inteligencia Artificial generativa. Las inversiones crecen, los equipos se especializan, las herramientas se vuelven más potentes. Y sin embargo, el patrón se repite: los equipos de negocio siguen sin obtener las respuestas que necesitan, y los equipos técnicos siguen construyendo soluciones que nadie termina de usar.

He trabajado en los dos lados de esa ecuación, desde el desarrollo hasta el análisis funcional, desde la parte técnica hasta la estratégica. Y puedo decirte con certeza: el problema casi nunca es tecnológico.

Cuando el único microscopio disponible era Excel

En una empresa de telecomunicaciones donde trabajé, los datos de tráfico llegaban como archivos planos: CDRs, registros de llamadas en crudo que había que procesar, transformar y convertir en algo inteligible. Construí sistemas en Java que leían esos archivos y los volcaban a bases de datos Oracle. Luego hice lo mismo con SQL Server, extrayendo información de un Data Warehouse de llamadas internacionales y transformándola en reportes para las áreas comerciales.

No existía Power BI. No existían dashboards en la nube. No había modelos de Machine Learning al alcance de un equipo corporativo. Lo que existía era Excel, criterio analítico y la necesidad urgente de entender qué estaba pasando con el tráfico, los clientes y los ingresos.

Hacer análisis en ese contexto era data mining en su forma más pura: tablas dinámicas, cruce de variables, búsqueda de patrones a ojo. Sin algoritmos de clustering. Sin modelos predictivos. Solo alguien capaz de hacerse las preguntas correctas y buscar las respuestas en la data.

Con el tiempo, automaticé ese flujo completo: los reportes se generaban solos en Java, se segmentaban por región y llegaban directamente a cada área comercial sin que nadie tuviera que pedirlos. No porque la tecnología fuera extraordinaria, sino porque había entendido exactamente qué necesitaba cada área y cuándo lo necesitaba.

El valor no estaba en el pipeline. Estaba en saber qué información convertía una decisión vaga en una decisión inteligente.

Los directores comerciales no pedían modelos predictivos ni algoritmos. Pedían saber qué clientes estaban creciendo, qué regiones estaban cayendo y dónde había una oportunidad que todavía no estaban viendo. La tecnología era el medio. La pregunta correcta era el destino.

El divorcio que ninguna herramienta ha resuelto

Hoy las organizaciones tienen herramientas extraordinarias: plataformas cloud, dashboards interactivos, modelos de Machine Learning, pipelines en tiempo real. Y aun así, una proporción enorme de proyectos de datos no generan el impacto esperado.

La razón es estructural, no técnica.

Existe una brecha profunda entre quienes entienden el negocio y quienes construyen las soluciones. El área comercial pide "un análisis de clientes" y recibe una tabla con doscientas columnas. El equipo de ingeniería construye un modelo precioso que nunca se conecta a ninguna decisión real. Los dashboards se llenan de métricas que nadie consulta después del primer mes.

Esa brecha no se cierra con más tecnología. Se cierra con personas capaces de moverse en los dos mundos: entender el dolor real del negocio y traducirlo en algo que la tecnología pueda resolver.

Por qué el mercado busca perfiles híbridos y no es una moda

Revisando el mercado laboral en datos, IA y transformación digital, hay un patrón que se repite en casi todas las ofertas relevantes: las organizaciones buscan perfiles híbridos. Personas que puedan sentarse con un CFO o un Director Comercial y entender su problema real. Personas que conozcan los datos, los procesos y las limitaciones técnicas. Personas capaces de construir el puente.

No es una tendencia pasajera. Es el reconocimiento tardío de que el valor no está en tener el modelo más sofisticado. Está en que ese modelo ayude a tomar una mejor decisión.

Un Data Engineer brillante que no entiende el negocio construirá pipelines perfectos hacia ningún lugar. Un directivo que no entiende los datos tomará decisiones bien intencionadas sobre información mal interpretada. El valor real está en el puente entre ambos mundos.

Lo que la Inteligencia Artificial no puede hacer por ti

Los agentes inteligentes de hoy pueden hacer en minutos lo que antes tomaba días: consultar bases de datos, cruzar fuentes, generar reportes, detectar anomalías. Eso es real y es transformador.

Pero hay algo que la IA no puede hacer por sí sola: definir cuál es la pregunta correcta.

Si la organización no tiene claridad sobre qué problema intenta resolver, la IA solo va a acelerar la confusión. Más velocidad en la dirección equivocada sigue siendo la dirección equivocada.

Cuando existe alguien que entiende el negocio y entiende la tecnología, la IA se convierte en un multiplicador extraordinario. Lo que antes requería construir un sistema de automatización completo hoy puede orquestarse en una fracción del tiempo. Pero alguien tiene que saber qué orquestar y para qué.

La habilidad más escasa en la era de los datos

He visto evolucionar esta industria desde los CDRs en archivos planos hasta los modelos generativos. Los lenguajes han cambiado, las plataformas han cambiado, los buzzwords cambian religiosamente cada tres años.

Lo que no ha cambiado es esto: las organizaciones necesitan personas capaces de sentarse con alguien del negocio, entender su dolor real, y traducirlo en algo que la tecnología pueda resolver. No es una habilidad blanda. Es posiblemente la más difícil de desarrollar y la menos enseñada en cualquier programa técnico o MBA.

En la era de la Inteligencia Artificial, esa habilidad no se vuelve obsoleta. Se vuelve escasa. Y lo escaso, como siempre, es lo más valioso.

¿Lo has vivido en tu organización? Me interesa tu perspectiva en los comentarios.

Cinco cambios que ya estamos viendo en la banca impulsada por la IA

2026-06-06T17:21:07.691-07:00

Cinco señales que ya estamos viendo en la banca impulsada por la IA

Introducción

Llevo más de quince años participando en proyectos tecnológicos para bancos y empresas de telecomunicaciones. A lo largo de este tiempo he coordinado implementaciones, gestionado riesgos, articulado equipos técnicos con áreas de negocio y participado en iniciativas que van desde infraestructura crítica hasta proyectos de ciberseguridad en entornos altamente regulados.

Hoy, mientras sigo de cerca la evolución del sector desde mi rol como consultora independiente y desde mi experiencia trabajando con herramientas y agentes de inteligencia artificial, noto algo que pocas personas están comentando con suficiente claridad.

La conversación sobre inteligencia artificial en la banca está cambiando mucho más rápido de lo que parece desde afuera.

Y no me refiero a los titulares sobre ChatGPT ni a las demostraciones tecnológicas que suelen captar la atención del mercado. Me refiero a las señales que aparecen cuando se observa con detenimiento lo que están haciendo los bancos, hacia dónde se están dirigiendo las inversiones y cómo las organizaciones comienzan a incorporar estas capacidades en su operación diaria.

Lo que veo es una transformación más profunda que la simple adopción de una nueva tecnología.

Esto no es un informe de consultoría ni una predicción sobre lo que ocurrirá dentro de diez años. Son observaciones basadas en lo que está sucediendo hoy, vistas desde una perspectiva que combina experiencia en el sector financiero con práctica directa en inteligencia artificial aplicada.

Estas son cinco señales que considero especialmente relevantes para entender hacia dónde se está moviendo la banca.

Señal 1: La IA está dejando de ser un proyecto para convertirse en una capacidad organizacional

Hace unos años, cuando se hablaba de inteligencia artificial en los bancos, la conversación giraba en torno a proyectos piloto. Un chatbot aquí, un modelo de scoring allá, una prueba de concepto en algún proceso interno.

Eso está cambiando.

Lo que estoy observando ahora es algo cualitativamente diferente: algunos bancos están creando estructuras organizacionales completas dedicadas a la transformación basada en IA. No un equipo de innovación aislado. No un laboratorio experimental. Sino una capacidad corporativa que atraviesa toda la organización.

BBVA es quizás el ejemplo más visible. Harvard Business Review lo estudia como referente global, no porque haya lanzado un producto llamativo, sino porque logró algo mucho más difícil: que más del 50% de sus empleados usen IA generativa cada semana. No solo los equipos técnicos. Toda la organización, incluyendo la red comercial.

Eso no ocurre por accidente. Ocurre cuando una institución decide que la IA no es una herramienta para algunos, sino una capacidad que debe integrarse en la forma de trabajar de todos.

La señal que veo aquí es esta: la ventaja competitiva ya no estará en quién desarrolla el mejor modelo. Estará en quién construye la capacidad organizacional para operar con IA de manera sostenible y a escala.

Y esa es una conversación muy diferente a la de hace tres años.

Señal 2: El canal ya no importa tanto como la presencia donde está el cliente

Una de las señales más interesantes que he observado recientemente tiene que ver no con tecnología sofisticada, sino con una decisión estratégica muy concreta: ir donde el cliente ya está.

Mibanco lanzó banca por WhatsApp. En Perú, WhatsApp no es solo una aplicación de mensajería. Es el canal de comunicación principal de millones de personas, incluyendo los microempresarios que son el corazón del negocio de Mibanco. Desde esa plataforma, los clientes pueden verificar préstamos aprobados, abrir cuentas de ahorro, consultar saldos, hacer transferencias y resolver dudas en horario extendido.

Esto me parece relevante por una razón que va más allá de la comodidad del usuario.

Durante años, la transformación digital bancaria se midió en términos de aplicaciones móviles descargadas, usuarios activos en banca por internet, o transacciones digitales procesadas. La lógica era: construye el canal digital y el cliente migrará hacia él.

Lo que estoy viendo ahora es una lógica diferente: en lugar de pedirle al cliente que adopte un nuevo canal, ir directamente al canal donde el cliente ya opera.

Es hiperpersonalización en su forma más práctica. No personalización del producto, sino personalización del punto de contacto.

Y esto, combinado con la inteligencia artificial que puede gestionar conversaciones, procesar solicitudes y dar respuestas en tiempo real, abre posibilidades que hace cinco años hubieran sido muy complejas de implementar.

La pregunta que me hago es: ¿cuántos bancos peruanos están pensando en esta dirección, y cuántos siguen invirtiendo en canales digitales propios asumiendo que el cliente los encontrará?

Señal 3: Los agentes inteligentes están pasando de la experimentación a la operación real

Esta es quizás la señal que más me llama la atención, porque la he vivido de primera mano.

Hace algunos meses desarrollé mi propio agente de Inteligencia Artificial, al que llamé ELISA. Lo concebí como una herramienta para apoyar la gestión del conocimiento, la toma de decisiones y la automatización de contenido.

La experiencia me permitió descubrir algo que rara vez aparece en las demostraciones tecnológicas o en las presentaciones de marketing: implementar un agente es solo el comienzo.

Lo verdaderamente complejo viene después.

Mantenerlo actualizado cuando cambia el contexto, asegurar que las respuestas sean consistentes, gestionar los casos en los que no tiene suficiente información, supervisar su desempeño y garantizar que el proceso completo sea confiable requiere mucho más trabajo del que suele imaginarse.

Ahora imaginemos ese desafío a la escala de una institución financiera.

Lo que estoy observando en el sector es que algunos bancos están pasando de experimentar con agentes a incorporarlos gradualmente en sus operaciones. Ya no se trata únicamente de asistentes que responden preguntas. Comienzan a participar en actividades relacionadas con la atención al cliente, el análisis documental, la gestión del conocimiento, el cumplimiento regulatorio y otros procesos de negocio.

Esto representa un cambio importante en la forma en que las organizaciones utilizan la Inteligencia Artificial.

El agente deja de ser una demostración tecnológica para convertirse en una herramienta integrada al trabajo diario de la organización.

Y aquí aparece una pregunta que, en mi opinión, será cada vez más relevante para los sectores regulados como la banca:

Cuando un agente participa activamente en un proceso de negocio, la discusión deja de ser exclusivamente tecnológica.

La verdadera pregunta pasa a ser: ¿cómo lo supervisamos, cómo gestionamos sus riesgos y cómo garantizamos que actúe dentro de los límites definidos por la organización?

Esa conversación apenas está comenzando.

Señal 4: El costo de la IA se está convirtiendo en un problema real que nadie está gestionando bien

Esta señal me parece especialmente relevante porque toca un punto que la mayoría de las conversaciones sobre IA ignoran completamente.

"Tu factura de IA se triplicó... y nadie sabe explicar por qué."

Esa frase resume un problema que está emergiendo con fuerza en las organizaciones que ya están usando IA a escala. El gasto empresarial en IA generativa creció de 11.5 mil millones de dólares en 2024 a 37 mil millones en 2025. Hasta el 80% del gasto en GPU se destina a inferencia, no a entrenamiento. Y el 98% de los equipos de FinOps ya están gestionando gasto en IA.

Está surgiendo una nueva disciplina que se llama AI FinOps: la práctica de alinear el gasto en IA con el valor que genera para el negocio.

No es solo reducir costos. Es algo más sofisticado: medir qué decisiones de IA generan valor, optimizar tokens y arquitecturas para reducir costos sin sacrificar calidad, y gobernar el gasto de manera que sea sostenible.

Para las instituciones financieras esto tiene una dimensión adicional. Los bancos operan en entornos regulados donde cada proceso debe ser trazable, justificable y auditable. Eso aplica también a los procesos en los que participa la IA.

Lo que observo es que muchas organizaciones están invirtiendo en capacidades de IA sin tener todavía claridad sobre cómo medir su retorno real, cómo controlar los costos a medida que escalan, o cómo justificar esas inversiones frente a reguladores y comités de riesgo.

Esa brecha, entre la velocidad de adopción y la madurez en la gestión, es una de las señales que más me preocupa y al mismo tiempo más me parece una oportunidad.

Señal 5: Gobernar la IA se está convirtiendo en una ventaja competitiva, no en un obstáculo

Durante mucho tiempo, el marco regulatorio se percibió como un freno a la innovación tecnológica en la banca.

Lo que estoy observando ahora es algo diferente.

Las instituciones que están construyendo capacidades sólidas de gobierno de IA — políticas claras, procesos de supervisión, trazabilidad de decisiones, gestión de riesgos de modelos — no lo están haciendo solo para cumplir con el regulador. Lo están haciendo porque entienden que esa capacidad les va a permitir escalar más rápido y con menos riesgo que sus competidores.

Existen estándares internacionales como la ISO 42001, que establece un marco de gestión para sistemas de inteligencia artificial. No es solo un certificado. Es una forma de pensar sobre cómo una organización gestiona la IA de manera responsable: qué decisiones toma el modelo, cómo se supervisan, qué pasa cuando algo sale mal, y cómo se garantiza que el sistema siga alineado con los objetivos del negocio.

En el sector financiero peruano, todavía son pocas las organizaciones que están abordando este tema de manera sistemática. La mayoría está en modo de experimentación: implementar, ver qué pasa, ajustar. Eso funciona para un piloto. No funciona cuando la IA empieza a participar en procesos críticos que afectan a clientes, operaciones y cumplimiento regulatorio.

La señal que veo es esta: dentro de pocos años, la capacidad de gobernar la IA de manera efectiva va a separar a las instituciones que puedan escalarla de las que tengan que frenar porque el riesgo se volvió inmanejable.

Y esa capacidad no se construye de un día para otro.

Reflexión final: lo que todo esto significa para los profesionales de tecnología en banca

Llevo semanas observando estas señales y pensando en lo que implican no solo para las instituciones financieras, sino para los profesionales que trabajamos en tecnología dentro de ese sector.

La conversación ha cambiado.

Antes, el valor de un profesional de tecnología en banca se medía por su capacidad de gestionar proyectos, coordinar equipos, asegurar entregas. Todo eso sigue siendo importante. Pero hay algo nuevo que se está volviendo igual de relevante: la capacidad de entender cómo la IA se integra en los procesos de negocio, qué riesgos genera, cómo se gobierna, y cómo se mide su valor real.

No se trata de convertirse en científico de datos o en ingeniero de machine learning.

Se trata de desarrollar una perspectiva que combine el conocimiento del negocio financiero, la experiencia en gestión tecnológica, y la comprensión de cómo funciona la IA en la práctica — no en teoría.

Eso es exactamente lo que intento construir en mi propio trabajo. No solo hablar sobre IA, sino aplicarla, entender sus límites, y desde esa experiencia, contribuir a que las organizaciones la adopten de manera efectiva y sostenible.

Las cinco señales que comparto en este artículo no son predicciones. Son observaciones de alguien que sigue el sector con atención y que cree que la inteligencia artificial, bien gestionada, puede transformar genuinamente la manera en que los bancos sirven a sus clientes y operan internamente.

La pregunta ya no es si la IA va a cambiar la banca.

La pregunta es quién va a estar preparado para liderar ese cambio desde adentro.

La batalla por los recursos: el dilema que ningún PM puede evitar

2026-06-02T07:48:52.834-07:00

La batalla por los recursos: el dilema que ningún PM puede evitar

Uno de los problemas más frecuentes en organizaciones que gestionan múltiples proyectos de manera simultánea no está relacionado con la tecnología, el presupuesto o incluso el cronograma.

Está relacionado con las personas.

Más específicamente, con aquellos especialistas que participan en varios proyectos al mismo tiempo.

Arquitectos, especialistas de ciberseguridad, administradores de infraestructura, expertos en bases de datos o líderes técnicos suelen convertirse en recursos compartidos debido a su experiencia y conocimiento. El problema aparece cuando varios proyectos requieren simultáneamente su participación y todos consideran que su necesidad es prioritaria.

En teoría, la situación parece sencilla de resolver.

En la práctica, suele convertirse en una verdadera batalla por los recursos.

Cuando todos los proyectos son prioritarios

Durante años gestionando proyectos de tecnología, infraestructura y ciberseguridad he escuchado frases similares:

Este proyecto es estratégico para la compañía.
Este cliente es el más importante.
Esta auditoría es obligatoria.
Esta implementación no puede retrasarse.
Esta ventana ya fue aprobada.

El problema aparece cuando todas estas afirmaciones son ciertas al mismo tiempo.

Cada Project Manager conoce perfectamente los riesgos, compromisos y fechas límite de su proyecto. Desde su perspectiva, la necesidad es urgente y justificada.

Sin embargo, el especialista sigue siendo uno solo.

Es en ese momento donde comienza la negociación.

El error de pensar que los recursos son infinitos

Los modelos de planificación suelen mostrar porcentajes de asignación:

Proyecto A: 30%
Proyecto B: 30%
Proyecto C: 20%
Proyecto D: 20%

Sobre el papel parece razonable.

Sin embargo, la realidad suele ser muy diferente.

Cada proyecto implica reuniones, coordinaciones, correos, revisiones técnicas, actividades urgentes, incidencias y ventanas de mantenimiento.

El cambio constante de contexto genera una pérdida de productividad que rara vez aparece reflejada en los indicadores.

Un especialista puede estar asignado formalmente al 100% de su capacidad y aun así sentirse completamente sobrecargado.

El recurso no es una máquina

Uno de los errores más frecuentes en la gestión multiproyecto es asumir que los recursos pueden dividirse matemáticamente sin afectar su desempeño.

Las personas no funcionan como servidores virtuales.

No basta con repartir porcentajes.

Con frecuencia he escuchado comentarios de especialistas que terminan una ventana de mantenimiento para conectarse inmediatamente a otra actividad crítica.

También he visto situaciones donde dos proyectos programan ventanas simultáneas y requieren exactamente al mismo especialista al mismo tiempo.

En esos casos aparecen problemas que normalmente no figuran en los reportes ejecutivos:

Fatiga.
Pérdida de concentración.
Incremento de errores.
Retrasos en actividades críticas.
Ausencias por agotamiento.

Incluso los propios Project Managers pueden verse afectados.

Recuerdo una ocasión en la que tuve que coordinar tres ventanas consecutivas antes de salir de vacaciones.

El trabajo se completó exitosamente.

Sin embargo, el nivel de desgaste acumulado fue tan alto que al día siguiente prácticamente dormí durante toda la jornada.

Ese tipo de situaciones rara vez aparece en los indicadores del proyecto, pero tiene un impacto directo en la productividad y sostenibilidad del equipo.

Mi enfoque para resolver conflictos por recursos

A lo largo de mi experiencia he aprendido que escalar un problema demasiado rápido suele ser un error.

Por esa razón aplico un proceso progresivo de negociación.

Nivel 1: Conversar con el especialista

Mi primer paso siempre es conversar directamente con la persona involucrada.

Muchas veces existe flexibilidad para reorganizar actividades o priorizar determinadas tareas.

Si logramos un acuerdo y obtenemos un compromiso claro, el problema queda resuelto sin necesidad de involucrar a más personas.

Nivel 2: Negociar con otros líderes de proyecto

Si la primera alternativa no funciona, el siguiente paso consiste en conversar con los responsables de los otros proyectos.

En esta etapa se analizan opciones como:

Reprogramar actividades.
Intercambiar especialistas.
Ajustar ventanas.
Modificar prioridades temporales.

Con frecuencia es posible encontrar soluciones cuando todas las partes comparten información de manera transparente.

Nivel 3: Escalar al responsable del portafolio

Cuando los líderes de proyecto no logran alcanzar un acuerdo, el conflicto debe analizarse desde una perspectiva superior.

El responsable del portafolio posee una visión global de la organización y puede evaluar qué iniciativas generan mayor valor o presentan mayor riesgo.

En este nivel ya no se discute un proyecto aislado.

Se analiza el conjunto completo.

Nivel 4: Conversar con el sponsor o cliente

Si el conflicto continúa, llevo la situación al sponsor o cliente.

No para buscar culpables.

No para criticar a la organización.

No para decir que alguien no está colaborando.

El objetivo es explicar una realidad operativa.

Con la capacidad actual disponible, existe un riesgo de incumplimiento en los plazos comprometidos.

A partir de ese momento se abre una conversación sobre alternativas posibles:

Ajustar fechas.
Reducir alcance.
Incorporar recursos adicionales.
Cambiar prioridades.

En algunas ocasiones la propuesta es aceptada.

En otras, el sponsor escala la situación a niveles ejecutivos superiores.

Pero en ambos casos ocurre algo importante:

Se toma una decisión.

La peor situación para un PM

Muchas personas creen que el peor escenario es recibir una negativa.

Mi experiencia me ha enseñado algo diferente.

El peor escenario es que nadie tome una decisión.

Cuando los conflictos por recursos permanecen sin resolverse, los proyectos se paralizan, los equipos se frustran y los riesgos aumentan.

Por el contrario, cuando la situación se transparenta adecuadamente y se escala al nivel correcto, la organización puede decidir y seguir avanzando.

Reflexión final

Según las buenas prácticas de gestión de proyectos y portafolios, los recursos son activos limitados que deben asignarse para maximizar el valor organizacional.

Sin embargo, detrás de cada porcentaje de asignación existe una persona real con límites físicos, responsabilidades y capacidad finita.

Por eso, la gestión de recursos no consiste únicamente en mover nombres dentro de una herramienta de planificación.

Consiste en equilibrar prioridades, negociar intereses, gestionar expectativas y asegurar que las decisiones se tomen en el nivel adecuado.

Después de años trabajando en proyectos de tecnología y ciberseguridad, he llegado a una conclusión sencilla:

La mayoría de los conflictos por recursos tienen solución.

Lo que realmente marca la diferencia es la capacidad del Project Manager para conducir la conversación hasta que alguien con autoridad tome una decisión.

La Transformación del Project Manager en la Era de los Agentes IA: Democratizando la Complejidad

2026-05-26T14:29:16.325-07:00

La Transformación del Project Manager en la Era de los Agentes IA: Democratizando la Complejidad

En el año 2023 participé en un Congreso Internacional del PMI presentando una ponencia sobre Inteligencia Artificial aplicada a la Gestión de Proyectos. En ese momento gran parte de la conversación giraba alrededor de automatización, análisis predictivo, asistentes inteligentes y herramientas de apoyo para el Project Manager.

Algunas de las ideas compartidas en aquella presentación pueden revisarse aquí:

Transformación impulsada por IA: innovaciones en la gestión de proyectos

Tres años después, el escenario parece haber evolucionado mucho más rápido de lo que imaginábamos.

Hoy ya no hablamos únicamente de asistentes capaces de generar documentos, resumir reuniones o ayudarnos con la identificación de riesgos. Empezamos a hablar de agentes IA, automatización cognitiva, copilots empresariales, BPM inteligente y flujos autónomos capaces de ejecutar parte de las actividades operativas que durante años consumieron gran parte del tiempo de los equipos de proyectos.

Sin embargo, considero que el cambio actual es mucho más profundo.

La conversación ya no gira únicamente alrededor de automatizar tareas.

La verdadera transformación empieza a aparecer cuando observamos cómo la Inteligencia Artificial puede convertirse en una extensión de nuestras capacidades cognitivas y ayudarnos a navegar un entorno cuya complejidad crece a una velocidad que probablemente supera nuestra capacidad natural de absorción.

Los proyectos actuales combinan simultáneamente:

Cloud
Ciberseguridad
Riesgos
Cumplimiento regulatorio
Inteligencia Artificial
Automatización
Datos
Integraciones
Arquitecturas híbridas
Múltiples stakeholders
Ecosistemas tecnológicos cada vez más complejos

Durante años muchas organizaciones utilizaron profesionales altamente preparados para actividades excesivamente operativas:

Seguimiento manual
Consolidación de reportes
Actualización de estados
Reuniones repetitivas
Documentación constante
Coordinación manual entre áreas
Tareas administrativas de bajo valor estratégico

En muchos casos, el tiempo destinado a la creatividad, el análisis, la innovación y el pensamiento estratégico terminó siendo reemplazado por presión operativa y sobrecarga administrativa.

Pero existe un desafío adicional.

Muchas veces seguimos evaluando profesionales principalmente por listas de tecnologías específicas, herramientas puntuales o conocimiento aislado.

El entorno actual cambia demasiado rápido para asumir que el valor diferencial consistirá únicamente en memorizar más herramientas o acumular más términos técnicos.

Tal vez la pregunta ya no sea cuánto más puede cargar una persona.

Tal vez la pregunta correcta sea:

¿Cómo amplificamos las capacidades humanas?

Y precisamente allí es donde la IA empieza a cambiar el juego.

La Inteligencia Artificial no elimina la necesidad del Project Manager.

Puede democratizar el acceso a la complejidad.

Puede acelerar la comprensión de documentación extensa.

Puede ayudar a interpretar conceptos especializados.

Puede conectar conocimiento que antes se encontraba aislado entre equipos y especialistas.

Puede reducir barreras técnicas que históricamente limitaron acceso al conocimiento.

Y existe otra barrera que durante años limitó la participación de muchos profesionales: el idioma.

Durante mucho tiempo, no dominar un idioma adicional podía significar quedar fuera de proyectos, documentación crítica o conversaciones relevantes.

Hoy las capacidades de Inteligencia Artificial están cambiando parte de esa realidad.

Transcripción automática, traducción en tiempo real, asistentes conversacionales, resúmenes inteligentes y herramientas capaces de acelerar comprensión están reduciendo barreras que antes parecían permanentes.

Esto no significa que habilidades como la comunicación o el aprendizaje continuo pierdan valor.

Pero sí abre una pregunta interesante:

¿Seguimos evaluando el potencial futuro utilizando barreras diseñadas para un contexto tecnológico que ya cambió?

Porque comprender información no es lo mismo que asumir responsabilidad sobre ella.

La IA puede procesar información.

Puede conectar contexto.

Puede acelerar aprendizaje.

Puede amplificar capacidades.

Pero alguien continúa teniendo que:

Tomar decisiones
Liderar equipos
Gestionar cambios
Entender impactos
Conectar personas
Asumir accountability por los resultados

En mi presentación del 2023 mencionaba que el nuevo perfil del Project Manager requería pensamiento crítico, adaptabilidad, visión, comunicación, negociación, ética y entendimiento de tecnologías emergentes.

Hoy considero que esa transformación continúa acelerándose.

Tal vez el verdadero potencial de la Inteligencia Artificial no sea reemplazar personas.

Tal vez su verdadero potencial sea permitir que las personas dediquen menos tiempo a sobrevivir la complejidad y más tiempo a generar valor.

El futuro del Project Management probablemente no será más operativo.

Será más humano, más estratégico y amplificado por Inteligencia Artificial.

Porque la máquina puede empujar.

Pero el Project Manager sigue conduciendo.

Y tú, ¿crees que seguimos evaluando profesionales con reglas diseñadas para un mundo que ya cambió?

La IA no necesita más prompts: necesita control financiero, gobierno y trazabilidad

2026-05-22T09:46:40.675-07:00

La IA no necesita más prompts: necesita control financiero, gobierno y trazabilidad

Cada semana aparecen nuevas plataformas para crear agentes de Inteligencia Artificial. Bancos, fintechs y empresas medianas ya están experimentando con asistentes automatizados, copilots, motores de análisis y flujos inteligentes capaces de ejecutar tareas que hace apenas unos años requerían equipos completos.

La velocidad de adopción es impresionante. Sin embargo, mientras gran parte del mercado se concentra en las capacidades técnicas de la IA, existe una conversación mucho más importante que todavía no está recibiendo suficiente atención: el gobierno operacional y financiero de estas iniciativas.

El problema ya no es únicamente “cómo crear un agente IA”. El verdadero desafío comienza después de implementarlo.

Muchas organizaciones todavía no están evaluando adecuadamente aspectos como la trazabilidad de las respuestas, el control de accesos, la dependencia tecnológica, el riesgo operacional, el consumo financiero asociado al uso de modelos y APIs, o la responsabilidad frente a errores generados por automatizaciones inteligentes.

En entornos regulados, como banca y servicios financieros, estos temas son especialmente sensibles. Un agente IA puede acelerar procesos, reducir tiempos de análisis y optimizar operaciones internas. Pero también puede amplificar errores, generar decisiones inconsistentes o introducir riesgos difíciles de identificar si no existe una estructura adecuada de supervisión y control.

Después de años participando en proyectos tecnológicos críticos relacionados con infraestructura, cloud y ciberseguridad, existe un patrón que suele repetirse: cuando la velocidad de implementación supera a la capacidad de gobierno, la organización empieza a acumular deuda operacional.

La IA no escapa a esa realidad.

El entusiasmo tecnológico no reemplaza el gobierno operativo

Actualmente muchas empresas están invirtiendo en automatización inteligente sin definir todavía elementos fundamentales como:

métricas de desempeño operacional;
límites de uso y consumo;
mecanismos de auditoría;
indicadores de retorno financiero;
controles de calidad de respuestas;
monitoreo continuo;
gestión de incidentes asociados a IA;
modelos de accountability frente a decisiones automatizadas.

En otras palabras, existe entusiasmo tecnológico, pero todavía falta madurez operacional.

La situación recuerda a muchas implementaciones tecnológicas del pasado: iniciativas que comenzaron con gran velocidad y expectativas elevadas, pero que posteriormente enfrentaron problemas de sobrecostos, falta de trazabilidad, dependencia excesiva de proveedores o ausencia de controles adecuados.

La diferencia es que, en el caso de la IA, la velocidad de escalamiento puede ser mucho mayor.

El problema financiero que muchas empresas todavía no están midiendo

Uno de los puntos menos discutidos es precisamente el financiero. En numerosos casos, las organizaciones comienzan pilotos de IA sin una estimación clara de costos recurrentes, consumo mensual, dependencia de proveedores externos o retorno esperado sobre la inversión.

Con frecuencia se subestima el impacto acumulado de elementos como:

consumo de APIs y tokens;
almacenamiento y procesamiento;
soporte operativo;
monitoreo y observabilidad;
integración con sistemas existentes;
supervisión humana;
costos de corrección de errores;
dependencia de plataformas externas.

Un análisis básico de flujo financiero para una iniciativa IA podría incluir elementos como los siguientes:

Concepto	Mes 1	Mes 2	Mes 3
Licencias y consumo IA	-800	-800	-800
Integración y configuración	-3000	0	0
Horas operativas y soporte	-1200	-1200	-1200
Ahorro en tareas manuales	+2500	+2500	+2500
Optimización de tiempos de análisis	+1800	+1800	+1800
Flujo estimado	-700	+2300	+2300

Aunque se trata únicamente de un ejemplo conceptual, el objetivo es evidenciar que la conversación sobre IA también debe incluir sostenibilidad financiera, medición de eficiencia y control operativo.

Errores frecuentes en iniciativas de agentes IA

En muchas organizaciones, el entusiasmo por implementar agentes inteligentes está avanzando más rápido que la definición de estructuras de control. Algunos errores frecuentes incluyen:

implementar automatización sin KPIs claros;
conectar agentes a información sensible sin políticas de gobierno;
no establecer límites de consumo o monitoreo financiero;
automatizar procesos que ya eran ineficientes;
no definir responsables operacionales;
depender completamente de proveedores externos;
asumir que la IA puede operar sin supervisión humana;
no considerar escenarios de falla o escalamiento.

Estos riesgos no son únicamente tecnológicos. También son financieros, operacionales y reputacionales.

Riesgos operacionales asociados a agentes IA

A medida que las organizaciones incrementen el uso de automatización inteligente, será necesario incorporar mecanismos de evaluación y monitoreo más estructurados.

Riesgo	Impacto	Mitigación
Respuestas erróneas	Alto	Supervisión humana
Sobreconsumo de APIs	Medio	Límites y alertas
Dependencia de proveedor	Alto	Estrategia multicloud
Exposición de datos sensibles	Alto	Gobierno y clasificación
Automatización incorrecta	Medio	Validación y pruebas
Falta de trazabilidad	Alto	Auditoría y monitoreo

Este tipo de análisis será cada vez más relevante en sectores regulados, donde la trazabilidad y el control forman parte de los requerimientos operacionales y de cumplimiento.

KPIs que probablemente serán clave en el gobierno de IA

En los próximos años, muchas organizaciones deberán empezar a monitorear indicadores específicos asociados al uso de Inteligencia Artificial. Algunos ejemplos incluyen:

costo promedio por interacción IA;
porcentaje de automatización efectiva;
tiempo promedio ahorrado;
tasa de corrección humana;
incidentes operacionales asociados a IA;
precisión de respuestas;
reducción de tiempos de análisis;
retorno estimado sobre inversión;
disponibilidad operacional de agentes;
cumplimiento de políticas de gobierno.

La IA ya no debería evaluarse únicamente por su capacidad de generar respuestas rápidas. También deberá medirse por su estabilidad, sostenibilidad y alineamiento con objetivos de negocio.

Conclusión

La adopción de agentes IA continuará acelerándose durante los próximos años. Sin embargo, el verdadero diferencial no será únicamente implementar automatización inteligente, sino hacerlo de manera controlada, trazable y financieramente sostenible.

La pregunta ya no es si las organizaciones utilizarán IA.

La verdadera pregunta es:

¿están preparadas para gobernarla?

¿Cómo manejas la presión?

2026-05-19T16:21:51.766-07:00

¿Cómo manejas la presión?

La pregunta parece sencilla… hasta que realmente te toca caminar dentro de la trinchera.

¿Qué haces cuando las tareas críticas no se cumplen?
Cuando el appliance de ciberseguridad no levanta y el proveedor tampoco tiene una respuesta inmediata.
Cuando la arquitectura propuesta no corresponde con la realidad encontrada en campo y el cableado ya está instalado.
Cuando un despliegue falla a pocas horas de una salida a producción.
Cuando el pipeline aparentemente está correcto, revisaste conexiones, accesos, troubleshooting, logs… y aun así nada funciona.
Cuando por cansancio humano alguien elimina un entorno UAT.
Cuando el equipo está exhausto.
Cuando el cliente presiona.
Cuando el timeline empieza a romperse.
Cuando el margen financiero se afecta.
Cuando no fue negligencia ni falta de monitoreo, sino simplemente un evento inesperado que tu estrategia no vio venir.

En esos momentos, cualquier Project Manager experimentado sabe lo que viene después:

Reuniones de emergencia.
Renegociación de alcance.
Fast tracking.
Crashing.
Liberaciones parciales para proteger continuidad operativa.
Reprogramación del workplan.
Automatización de tareas.
Escalamiento con fabricantes.
Contención ejecutiva.
Priorización de componentes críticos.

Todo eso está bien.
Todo eso forma parte del trabajo.

Pero hay una pregunta de la que se habla poco:

¿Cómo quedas tú?

Porque detrás de cada comité, cada incidente crítico y cada decisión bajo presión, hay una persona sosteniendo el accountability.

Y la inteligencia artificial podrá acelerar análisis, automatizar tareas y apoyar operaciones, pero incluso en los entornos más modernos seguirá existiendo alguien cargando la responsabilidad final cuando las cosas no salen como se esperaba.

¿Cómo mantienes serenidad cuando el problema todavía no tiene una solución clara?
¿Cómo sigues tomando decisiones cuando el cansancio empieza a nublar la mente?
¿Cómo sostienes estructura en medio del caos?

En mi caso, ese soporte viene de mi fe.

Hay una parte del Salmo 91 que siempre me hace reflexionar:

“Sobre el león y el áspid pisarás…”

Durante mucho tiempo pensé que ese versículo hablaba únicamente de peligros externos.
Hoy creo que también habla de esos momentos complejos que enfrentamos en silencio:

la presión,
la incertidumbre,
los entornos hostiles,
las situaciones que parecen acorralarnos profesionalmente.

Porque a veces el león no está afuera.
A veces el león es el miedo a fallar.
Y el áspid puede ser la incertidumbre silenciosa que acompaña las decisiones difíciles.

Puede que para otros la fortaleza venga desde otro lugar.
Y está bien.

Pero sí creo que en esta nueva era tecnológica estamos hablando mucho de herramientas, automatización e inteligencia artificial… y muy poco de resiliencia emocional, serenidad y fortaleza interior.

Porque al final, más allá de la tecnología, siempre habrá un ser humano tomando decisiones bajo presión.

Y quizás esa sea una de las capacidades más importantes para sobrevivir en entornos complejos sin perder claridad, humanidad ni dirección.

Cómo medir el ROI de la IA Agentica en el onboarding corporativo

2026-05-16T18:25:32.766-07:00

Cómo medir el ROI de la IA Agentica en el onboarding corporativo

Durante los últimos meses hemos visto una enorme cantidad de conversaciones sobre Inteligencia Artificial.

La mayoría enfocadas en:

generación de contenido,
automatización de tareas,
asistentes conversacionales,
o productividad individual.

Pero creo que uno de los impactos más importantes de la IA Agentica podría estar en un lugar mucho menos visible:

el onboarding corporativo.

Hace poco leí el caso de una persona que ingresó a una empresa donde los agentes IA ya forman parte del entorno operativo diario.

Lo interesante no fue que el agente escribiera código o resumiera documentos.

Lo verdaderamente interesante fue esto:

en apenas 4 días la persona sentía que entendía el contexto operativo de la organización como si hubiera trabajado allí durante meses.

Y eso me hizo pensar en algo que probablemente muchos hemos vivido.

El onboarding tradicional: la fricción que normalizamos

Cuando ingresamos a una nueva organización normalmente existe entusiasmo.

Queremos demostrar resultados rápidamente.
Queremos entender el negocio.
Queremos aportar valor.

Pero la realidad operacional suele verse muy distinta.

Esperar accesos.
Esperar aprobaciones.
Esperar equipos.
Esperar configuraciones.
Esperar reuniones.
Esperar que alguien tenga tiempo para explicar cómo funciona realmente el entorno.

Y aunque muchas organizaciones consideran esto “normal”, en realidad representa una enorme fricción operacional.

Porque el problema no es únicamente la demora técnica.

El verdadero problema es el acceso al contexto.

El conocimiento organizacional rara vez está realmente estructurado

En teoría, toda la información debería estar documentada.

Pero en la práctica:

parte está en correos,
parte en chats,
parte en reuniones,
parte en videos,
parte en carpetas compartidas,
y muchas veces la información más importante vive únicamente en la experiencia de ciertas personas.

Entonces aparece un ciclo bastante conocido:

preguntar,
esperar respuesta,
buscar documentación,
leer información incompleta,
volver a preguntar,
agendar reuniones,
y repetir nuevamente el proceso.

Muchas veces los compañeros sí quieren ayudar.

Pero también están atendiendo:

incidentes,
proyectos,
comités,
entregables,
auditorías,
producción,
o su propia carga operativa diaria.

El resultado es una curva de aprendizaje mucho más lenta de lo que debería ser.

Y no necesariamente por falta de talento.

Sino por la enorme dificultad para acceder al contexto correcto en el momento correcto.

El problema del “conocimiento tribal”

En muchas organizaciones existe algo que normalmente se conoce como conocimiento tribal.

Información crítica que nunca quedó realmente estructurada.

Por ejemplo:

decisiones históricas,
dependencias ocultas,
configuraciones especiales,
problemas recurrentes,
criterios operativos,
acuerdos no documentados,
o razones por las cuales ciertos procesos funcionan de determinada manera.

Y cuando una nueva persona necesita entender ese entorno, depende completamente de encontrar a la persona correcta… en el momento correcto.

El problema es que ese modelo no escala.

Y además genera riesgos importantes para:

continuidad operacional,
transferencia de conocimiento,
eficiencia,
y sostenibilidad organizacional.

¿Qué cambia con la IA Agentica?

Aquí es donde la conversación empieza a ponerse realmente interesante.

Porque la IA Agentica no solo permite responder preguntas.

Permite conectar contexto.

Imaginemos un entorno donde un agente pueda:

resumir decisiones históricas,
identificar documentación relevante,
explicar procesos,
mapear dependencias,
priorizar información según el rol del colaborador,
e incluso acelerar la comprensión del entorno operativo desde el primer día.

No como un chatbot decorativo.

Sino como una capa de memoria institucional.

Y ahí es donde creo que aparece uno de los ROI más subestimados de la IA.

Porque el valor no estaría únicamente en automatizar tareas.

El valor estaría en reducir fricción organizacional.

El costo invisible del onboarding

Muchas veces las organizaciones no miden realmente el impacto operativo del onboarding.

Pero cuando observamos el proceso completo aparecen múltiples factores:

interrupciones constantes,
dependencia de personal senior,
búsqueda manual de información,
reuniones repetitivas,
retrabajo,
errores por falta de contexto,
y largos periodos hasta lograr autonomía operativa.

En sectores complejos como:

banca,
telecomunicaciones,
tecnología,
ciberseguridad,
o transformación digital,

este impacto puede extenderse durante semanas o incluso meses.

Y aunque cada organización tiene realidades distintas, sí es posible visualizar conceptualmente la diferencia entre ambos escenarios.

Escenario 1 — Onboarding tradicional

Actividad	Semana 1	Semana 2	Semana 3	Semana 4	Horas
Espera accesos/aprobaciones	12	4	0	0	16
Reuniones onboarding	10	8	6	4	28
Interrupciones senior	12	14	10	6	42
Búsqueda documentación	14	16	12	8	50
Lectura información incompleta	10	8	6	4	28
Re-trabajo y aclaraciones	6	10	12	8	36
Conocimiento tribal	8	12	10	6	36
Curva aprendizaje	40	40	40	40	160
Productividad parcial perdida	40	40	32	24	136
Carga operacional acumulada					532

Este modelo no busca monetizar directamente el onboarding, sino visualizar la carga operacional acumulada que normalmente permanece invisible dentro de muchas organizaciones.

Escenario 2 — Onboarding con IA Agentica

Actividad	Semana 1	Semana 2	Horas
Configuración inicial y permisos	6	0	6
Validaciones humanas puntuales	4	2	6
Consultas estratégicas a líderes	2	2	4
Búsqueda contextual automatizada	2	1	3
Lectura guiada/priorizada	6	4	10
Aprendizaje acelerado	12	8	20
Ajustes operativos menores	4	2	6
Productividad parcialmente reducida	8	4	12
Carga operacional acumulada			67

La IA Agentica no elimina el onboarding. Elimina gran parte de la fricción operacional que históricamente lo ha ralentizado.

Delta Operacional

Indicador	Tradicional	IA Agentica	Impacto
Carga operacional acumulada	532 horas	67 horas	↓ Menos fricción operacional
Tiempo hasta autonomía	2 a 6 meses	4 días a 2 semanas	↓ Onboarding acelerado
Dependencia senior	Alta	Puntual	↓ Menos interrupciones
Búsqueda de información	Manual	Contextual	↓ Menos tiempo perdido
Transferencia de conocimiento	Fragmentada	Guiada	↑ Más velocidad de aprendizaje
Re-trabajo	Frecuente	Reducido	↓ Menor desgaste
Conocimiento histórico	Disperso	Centralizado	↑ Memoria institucional
Productividad inicial	Lenta	Acelerada	↑ Valor temprano
Riesgo conocimiento tribal	Alto	Mitigado	↓ Menor dependencia crítica
Conclusión	Fricción alta	Fricción reducida	Mayor eficiencia operativa

Los valores mostrados representan un escenario conceptual orientado a visualizar la reducción de fricción operacional y aceleración del aprendizaje organizacional mediante IA Agentica.

Gobernanza, seguridad y límites

Por supuesto, este escenario también abre desafíos importantes.

Porque un agente corporativo no puede tener acceso ilimitado a toda la información organizacional.

Aquí aparecen preguntas críticas:

¿Qué permisos debería tener?
¿Cómo se protegen datos sensibles?
¿Cómo se valida la información entregada?
¿Cómo se controlan respuestas incorrectas?
¿Cómo se mantiene trazabilidad?
¿Cómo se gobierna la memoria institucional?

Especialmente en sectores regulados, la IA Agentica necesita combinar:

contexto,
seguridad,
compliance,
trazabilidad,
y control de accesos.

Porque sin gobernanza, el riesgo operacional también crece.

El verdadero cambio no es tecnológico

Y quizás esta sea la parte más importante.

Creo que el mayor impacto de la IA empresarial no estará únicamente en automatizar tareas individuales.

Estará en transformar la manera en que las organizaciones:

capturan conocimiento,
conectan contexto,
aceleran aprendizaje,
y reducen fricción operacional.

Porque muchas veces el problema no es falta de talento.

El problema es la enorme dificultad para acceder al contexto correcto en el momento correcto.

Y honestamente…
creo que ahí podría estar uno de los mayores ROI reales de la IA Agentica dentro del entorno corporativo moderno.

Cómo justificar financieramente iniciativas IA

2026-05-14T12:00:26.339-07:00

Cómo justificar financieramente iniciativas IA

La conversación sobre Inteligencia Artificial ha cambiado radicalmente en los últimos dos años.

Hoy prácticamente todas las organizaciones hablan de:

copilots,
agentes IA,
automatización,
productividad,
y transformación digital.

Sin embargo, existe una brecha enorme entre el entusiasmo inicial y el valor financiero realmente capturado.

Mientras las inversiones continúan creciendo, muchas iniciativas IA siguen atrapadas en:

pilotos,
pruebas de concepto,
automatizaciones aisladas,
o soluciones sin impacto sostenible en el negocio.

El problema no siempre es la tecnología.

En muchos casos, el verdadero problema es financiero, operativo y de gobierno.

La IA no se justifica únicamente porque “funciona”.
Debe justificarse porque:

genera retorno,
mejora indicadores,
reduce costos,
acelera decisiones,
o crea ventajas operativas medibles.

Y eso requiere una conversación mucho más madura que simplemente implementar un chatbot.

Paso 1 — Definir el problema operativo antes de hablar de IA

Uno de los errores más comunes en iniciativas IA es comenzar desde la tecnología en lugar del problema de negocio.

Por ejemplo:

“queremos usar IA”
“necesitamos un agente”
“debemos implementar copilots”

Pero pocas organizaciones responden primero:

¿Qué proceso exacto queremos mejorar?
¿Dónde existe fricción operativa?
¿Qué actividad consume tiempo o recursos?
¿Qué KPI necesita mejorar?

La IA no debería implementarse por tendencia.
Debe implementarse para resolver un problema operativo específico.

Sin esta definición inicial, muchas iniciativas terminan convirtiéndose en pilotos sin retorno claro.

Paso 2 — Identificar el KPI financiero que realmente cambiará

Toda iniciativa IA debería estar asociada a una métrica concreta.

Por ejemplo:

reducción de tiempo operativo,
disminución de errores,
ahorro de costos,
incremento de productividad,
reducción de backlog,
mejora en tiempos de atención,
disminución de riesgo operativo,
automatización de tareas repetitivas.

Uno de los principales problemas actuales es que muchas organizaciones implementan IA sin definir cómo medirán el éxito financiero del proyecto.

Si no existe un KPI claro:

el ROI nunca será visible,
el valor nunca podrá demostrarse,
y el proyecto terminará dependiendo únicamente de percepción o entusiasmo ejecutivo.

Paso 3 — Calcular los costos ocultos de la IA

Aquí aparece una de las mayores diferencias entre el discurso comercial y la realidad operativa.

La mayoría de iniciativas IA no fracasa por el modelo.

Fracasa porque los costos reales son mucho mayores de lo esperado.

Cuando una organización implementa IA, no solo debe considerar:

licencias,
nube,
o consumo de tokens.

También aparecen costos relacionados con:

integración,
soporte,
monitoreo,
gobierno,
entrenamiento,
trazabilidad,
calidad de datos,
seguridad,
adopción organizacional,
mantenimiento operativo,
y continuidad.

En iniciativas basadas en agentes IA, la complejidad aumenta aún más.

Un agente empresarial no solo “responde preguntas”.
Necesita:

acceder a sistemas,
interactuar con APIs,
ejecutar acciones,
consultar información sensible,
y dejar trazabilidad de sus actividades.

Eso transforma completamente la ecuación financiera y de riesgo.

Paso 4 — Evaluar gobierno, accesos y trazabilidad

Uno de los temas menos discutidos actualmente es el gobierno de agentes IA.

Muchas organizaciones todavía se encuentran explorando copilots aislados.
Pero cuando la IA comienza a interactuar con sistemas reales:

ERP,
CRM,
plataformas financieras,
workflows corporativos,
herramientas de atención,
o repositorios documentales,

la conversación deja de ser únicamente tecnológica.

Se convierte en una conversación de:

gobierno,
compliance,
IAM,
auditoría,
segregación de funciones,
privacidad,
y control operativo.

Aquí aparecen preguntas críticas:

¿Qué permisos tendrá el agente?
¿Qué acciones podrá ejecutar?
¿Qué información podrá consultar?
¿Cómo se registrará la trazabilidad?
¿Cómo se controlará el uso indebido?
¿Cómo se gestionará Shadow AI?

Muchas organizaciones todavía no tienen respuestas maduras para estos escenarios.

Paso 5 — Construir un modelo financiero simple antes de escalar

No toda iniciativa IA necesita comenzar con un business case extremadamente complejo.

Pero sí debería existir al menos un modelo financiero mínimo que permita visualizar:

inversión inicial,
costos recurrentes,
beneficios esperados,
payback,
riesgos,
timeline,
y sostenibilidad operativa.

Un error frecuente es asumir que la IA generará retorno inmediato.

En la práctica, muchas iniciativas requieren:

maduración,
ajustes operativos,
integración,
entrenamiento organizacional,
y evolución continua antes de capturar valor real.

Por eso, el ROI en IA muchas veces debe evaluarse como:

una transformación operativa progresiva,
y no simplemente como una automatización tradicional.

Copilots no son lo mismo que agentes IA

Actualmente muchas organizaciones mezclan ambos conceptos.

Sin embargo, existe una diferencia importante.

Copilots

Generalmente:

asisten,
generan contenido,
resumen información,
ayudan al usuario,
pero no ejecutan acciones críticas.

Agentes IA

En cambio:

toman decisiones,
interactúan con sistemas,
ejecutan workflows,
automatizan procesos,
y requieren gobierno mucho más robusto.

Eso implica:

mayor complejidad,
mayor riesgo,
mayor costo operativo,
y también mayor potencial de retorno.

Reflexión final

La IA no debería evaluarse únicamente por:

cantidad de prompts,
demos,
o pilotos rápidos.

La verdadera conversación empresarial está comenzando recién ahora:

cómo gobernarla,
cómo integrarla,
cómo operarla,
y sobre todo,
cómo justificar financieramente su sostenibilidad.

Porque la diferencia entre una demo interesante y una iniciativa IA rentable no suele estar en el modelo.

Suele estar en:

la operación,
el gobierno,
los costos ocultos,
y la capacidad real de capturar valor a largo plazo.

Referencias

MIT / State of AI in Business Report 2025

Deloitte – AI ROI: The paradox of rising investment and elusive returns

Google Cloud – ROI of AI 2025