¿Es realmente posible crear agentes de IA de nivel empresarial en tan solo unas horas?

Una guía práctica para ejecutivos que se enfrentan al cambio hacia la agencia

Normalmente todo comienza en una sala de reuniones. Un proveedor abre su ordenador portátil, escribe una sola frase en el chat y observa cómo un agente extrae el código data de tres sistemas, resume un contrato de arrendamiento, señala una cláusula para su revisión jurídica y envía el resultado por correo electrónico al equipo de gestión de activos. Todo el proceso dura noventa segundos. Se hace el silencio en la sala y, a continuación, alguien pregunta: “¿Cuánto tiempo se tardó en desarrollar eso?”. La respuesta, “una tarde”, es el momento en el que la mayoría de las estrategias empresariales de IA se replantean discretamente.

Es una pregunta razonable y, a primera vista, apasionante. Si se puede crear un agente funcional en una tarde, ¿por qué seguimos dedicando dieciocho meses a cada transformación digital? ¿Por qué pagamos sumas de siete cifras por un software que ofrece menos prestaciones? Y, lo que es más urgente, ¿qué deberíamos hacer al respecto?

La respuesta sincera es más matizada de lo que sugiere la demostración. Sí, sin duda alguna se puede crear un agente de IA operativo en unas pocas horas. Las herramientas actuales son así de buenas. Sin embargo, la diferencia entre un agente operativo y uno de nivel empresarial es mayor de lo que la mayoría de los directivos esperan, y es ahí donde residen prácticamente todos los costes, riesgos y valor reales.

Este artículo está dirigido a ejecutivos que deseen comprender qué es realmente posible hoy en día, qué resulta verdaderamente difícil y cómo actuar con rapidez sin tomar ese tipo de decisiones que parecen brillantes en mayo y resultan embarazosas en noviembre. Analizaremos qué son los agentes, qué no son, dónde operan, quiénes los desarrollan y qué se necesita para implementarlos adecuadamente en una empresa sujeta a regulación. Al finalizar, debería estar en condiciones de acudir a su próxima reunión de la junta directiva y explicar con claridad el panorama actual.

¿Qué es, en realidad, un agente de IA?

Antes de siquiera plantearnos la implementación, conviene detenernos a reflexionar sobre qué entendemos realmente por “agente de IA”. Los equipos de marketing han abusado enormemente de esta expresión en los últimos dieciocho meses, y la mayoría de los ejecutivos no saben muy bien si lo que les están vendiendo es un agente, un chatbot, una herramienta de flujo de trabajo o una macro especialmente eficaz.

La definición práctica más clara es la siguiente: un agente de IA es un programa informático que utiliza un modelo base para comprender un objetivo, planificar cómo alcanzarlo, actuar recurriendo a herramientas y sistemas, y adaptarse en función de lo que observa. Piense en él como un titulado universitario digital. Es competente, sabe leer instrucciones, sabe cómo pedir ayuda, puede utilizar las herramientas que se le proporcionen y, dentro de un ámbito de competencia definido, es capaz de tomar decisiones sensatas sin necesidad de una supervisión constante. Al igual que un titulado universitario, se beneficia de unas pautas claras y de que un compañero con más experiencia revise su trabajo de mayor trascendencia.

Desde el punto de vista de su estructura, cada agente se basa en cinco capacidades. Un modelo base proporciona el motor de razonamiento; por ejemplo, Claude ‘Sonnet’, GPT ‘4o’ o Gemini ‘3.5 Flash’. Las herramientas dotan al agente de la capacidad de actuar: consultar una base de datos data, enviar un correo electrónico, recuperar un documento o realizar un cálculo. La memoria le permite conservar el contexto a lo largo de los pasos y, en el caso de los agentes más sofisticados, a lo largo de las sesiones. La orquestación se encarga de la planificación y el enrutamiento: decidir qué hacer a continuación, cuándo escalar el problema y cuándo detenerse. Y las barreras de seguridad definen los límites: lo que el agente está autorizado a hacer, a qué datos puede acceder y cuándo es necesaria la aprobación de un ser humano.

Figura 1. Los cinco componentes de un agente de inteligencia artificial.

Esta estructura es importante porque explica en qué se diferencian los agentes de aquellos elementos con los que a menudo se les confunde. Un chatbot cuenta con el modelo y, posiblemente, cierta memoria, pero carece de herramientas reales y de capacidad de coordinación; habla, pero no actúa. La RPA dispone de herramientas y capacidad de coordinación, pero carece de razonamiento: sigue un guion y falla en cuanto la realidad se desvía de él. El aprendizaje automático tradicional cuenta con un razonamiento de tipo limitado, pero carece de inteligencia general, de uso de herramientas y de interfaz conversacional. Un agente combina los cinco componentes. Eso es lo que lo hace útil, y eso es lo que lo hace novedoso.

Conviene tener en cuenta otra distinción más: los agentes son probabilísticos, no deterministas. En ocasiones, realizarán acciones inesperadas. Esta característica resulta ventajosa en muchos casos de uso, ya que les permite gestionar esos casos límite complejos que supusieron un obstáculo para las generaciones anteriores de automatización; sin embargo, en otros casos puede suponer un inconveniente. Saber distinguir entre ambos casos constituye la mayor parte del trabajo.

Una taxonomía que los directivos realmente necesitan

Si el término “agente de IA” abarca desde un informe diario programado hasta un sistema de negociación autónomo, ha dejado de ser útil. En consonancia con la forma en que Gartner, Forrester y las principales plataformas describen actualmente este ámbito, nos resulta útil plantearlo como un espectro compuesto por cinco categorías con un grado de autonomía cada vez mayor.

Figura 2. Una taxonomía operativa de los sistemas agenciales.

Acciones programadas se sitúan en el extremo más sencillo. Se trata de procesos de automatización que se ejecutan mediante un temporizador o un desencadenante: un informe diario de KPI, una limpieza de la bandeja de entrada a las 7 de la mañana, un webhook que se activa cuando se cierra una operación en el CRM. Pueden utilizar un modelo de lenguaje grande (LLM) para un solo paso (resumir un documento, redactar un correo electrónico), pero no razonan sobre qué hacer a continuación. La mayoría de los ejecutivos ya cuentan con varias de estas soluciones; antes del cambio de denominación de marketing, se denominaban “automatización”.

Agentes de tareas Añada al panorama una única tarea específica impulsada por un modelo de lenguaje grande (LLM). Un ejemplo típico: un agente que lee cada correo electrónico recibido, lo clasifica por tema y urgencia, y lo remite al equipo adecuado. Implica un proceso de razonamiento, pero solo en un único punto. El flujo que lo rodea es determinista. Estas soluciones resultan extremadamente útiles, muy económicas y constituyen el punto de partida natural para la mayoría de las organizaciones.

Agentes de automatización encadenar varios pasos dentro de un flujo de trabajo definido. Siguen estando sujetos a ciertas limitaciones, ya que los pasos se conocen de antemano, pero el modelo de lenguaje grande (LLM) toma decisiones en varios puntos: decide qué herramienta invocar, qué data recuperar y qué hacer si falla una comprobación. Un buen ejemplo es un flujo de aprobación de facturas que lee un PDF, extrae las partidas, las hace coincidir con las órdenes de compra y, a continuación, las aprueba o las remite para su revisión.

Agentes de flujo de trabajo son el ámbito en el que se está desarrollando hoy en día la mayor parte del trabajo empresarial verdaderamente apasionante. A estos agentes se les asigna un resultado, en lugar de una secuencia concreta, como por ejemplo: “resuma este contrato de arrendamiento de 80 páginas y señale cualquier aspecto que deba preocuparnos”, y son ellos mismos quienes deciden cómo lograrlo. Leerán documentos, consultarán sistemas, formularán preguntas de seguimiento y repetirán el proceso. El flujo de trabajo es emergente, en lugar de estar predefinido. Los modelos de razonamiento han aumentado drásticamente la fiabilidad de esta categoría en los últimos doce meses.

Sistemas multiagente son la vanguardia. Un agente coordinador divide un objetivo en subtareas y las delega a un especialista para cada una: uno para la investigación, otro para el análisis, otro para la redacción y otro para la revisión. Si se gestionan adecuadamente, los sistemas multiagente pueden llevar a cabo un trabajo que un único agente no podría realizar. Si, por el contrario, se gestionan de forma inadecuada, generan ocho veces más posibilidades de fallo para obtener el mismo resultado. La mayoría de las empresas no deberían comenzar por aquí.

Una pregunta útil que puede plantearse cuando un proveedor le ofrece algo es, sencillamente: ¿en qué punto de este espectro se sitúa? Si le muestran una acción programada y le cobran por un agente de flujo de trabajo, acaba de identificar la forma más habitual de sobreventa de agentes en el mercado. Por el contrario, si su equipo está intentando implementar un sistema multiagente como su primera implementación, anímeles con tacto a que empiecen una columna más a la izquierda.

¿Por qué ahora?

Llevan años prometiendo agentes. ¿Qué ha cambiado?

Se dieron tres factores. En primer lugar, los modelos base superaron el umbral de fiabilidad necesario para el uso de herramientas. Hace dos años, pedirle a un modelo que llamara a una API y utilizara el resultado era sinónimo de decepción; hoy en día, los modelos básicos de Claude, GPT y Gemini gestionan el uso de herramientas en varios pasos con una tasa de acierto lo suficientemente buena como para su uso en producción. En segundo lugar, los modelos de razonamiento: Claude con pensamiento ampliado, la serie «o» de OpenAI y los modos de razonamiento más profundos de Gemini han mejorado significativamente el rendimiento en el tipo de tareas de varios pasos que requieren un alto grado de criterio, tal y como exigen los flujos de trabajo reales. En tercer lugar, por fin se dispone de la infraestructura necesaria: marcos de orquestación como LangGraph y CrewAI, o bien alguna de las numerosas soluciones de flujos de trabajo «low-code»; herramientas de evaluación para realizar pruebas sistemáticas; y el Protocolo de Contexto de Modelos (MCP), que ofrece a los agentes una forma estandarizada de integrarse con las docenas de sistemas en los que realmente opera una empresa.

La curva de costes también ha contribuido a ello. El precio por token de la inteligencia de vanguardia se ha reducido en un orden de magnitud en dos años, y el nivel «lightweight» (Claude Haiku, GPT-mini, Gemini Flash) resulta ahora lo suficientemente asequible como para aplicarse a la escala de cada correo electrónico o cada documento que genera una empresa.

El resultado es que nos encontramos en un momento que no se da con frecuencia: la tecnología es realmente capaz, las herramientas son realmente fáciles de usar y la viabilidad económica es real. Si a ello le sumamos que los marcos normativos comienzan a estabilizarse —la Ley de IA de la UE es una realidad conocida, en lugar de un objetivo en constante cambio—, y que los organismos reguladores del Golfo, incluida la SDAIA de Arabia Saudí, han publicado posiciones claras, el periodo 2025-2026 constituye el punto de inflexión en el que las empresas serias pasarán de la fase de experimentación a la de implantación.

La realidad de las “pocas horas”

Entonces, ¿es realmente posible crear un agente de nivel empresarial en unas pocas horas? Sí y no, y la diferencia entre ambas respuestas es precisamente el motivo por el que este artículo merece la pena.

Lo que sin duda puede crear en una tarde: un agente funcional que realice una tarea real. Elija un caso de uso, por ejemplo, resumir y clasificar el contenido de una bandeja de entrada compartida. Abra Claude Projects, n8n o la plataforma que prefiera. Configure el acceso a la bandeja de entrada, redacte una instrucción clara que describa la tarea, proporciónele una base de conocimientos con ejemplos anteriores y establezca un calendario. Al final de la tarde, dispondrá de un agente que realiza algo realmente útil. Muéstreselo a sus compañeros de trabajo. Quedarán impresionados. No se trata de un truco, sino de una muestra de lo mucho que han avanzado las herramientas subyacentes.

Lo que no se puede crear en una tarde es la diferencia entre esa demostración y algo que realmente se implementaría para dos mil empleados repartidos en tres jurisdicciones. Para lograrlo, se necesitan controles de acceso que garanticen que el agente solo vea lo que cada usuario está autorizado a ver. Necesita un registro de auditoría que recoja cada decisión y cada llamada a la herramienta. Necesita un marco de evaluación que le indique si el agente acierta el 95% de las veces o el 70%, y en qué aspectos tiende a equivocarse. Se necesitan controles de costes, ya que un agente que funcione sin supervisión puede agotar presupuestos de seis cifras en cuestión de días. Se necesitan puntos de control con intervención humana para las decisiones de gran repercusión. Se necesita que se gestione la residencia data para las regiones a las que les importa (y cada vez son más las que lo hacen). Necesita una ruta alternativa para cuando el modelo no esté disponible. Necesita observabilidad para que su equipo de operaciones pueda ver lo que está sucediendo. Y necesita un programa de gestión del cambio para que su personal utilice realmente el sistema.

Según nuestra experiencia, el esfuerzo necesario para preparar un sistema para la producción suele ser entre diez y veinte veces mayor que el requerido para el prototipo. Un agente que a un desarrollador le llevó tres días crear, a un pequeño equipo le llevará tres meses adaptarlo para que cumpla con los estándares empresariales. Esto no es un fallo de la tecnología. Es la realidad de llevar a cabo cualquier tarea de forma responsable dentro de una gran organización. El mismo factor multiplicador se aplica a la implantación de un CRM, a un sistema data platform o a la integración de pagos. La diferencia es que la demostración de esos proyectos no es tan buena como para hacerle olvidar el resto.

La forma correcta de interpretar la afirmación de “unas pocas horas” es la siguiente: los prototipos agentivos son ahora realmente económicos. La producción agentiva, en cambio, no lo es. La clave reside en saber distinguir entre ambos y en aprovechar el bajo coste de los primeros para tomar mejores decisiones sobre los segundos.

¿Cómo se crean realmente los agentes?

En la actualidad, existen tres formas generales de crear un agente, cada una con su propio audience, límite máximo y ventajas e inconvenientes.

Generadores visuales

Se trata de plataformas en las que se crean agentes arrastrando nodos por un lienzo. n8n, Make (antes Integromat), las soluciones de IA de Zapier y Copilot Studio de Microsoft son las principales opciones. El modelo se aloja en un nodo, las herramientas en otros, y se conectan entre sí mediante líneas. Los constructores visuales son espectaculares para la creación de prototipos y para casos de uso que se asemejan a la automatización clásica con un paso de LLM añadido. También son extraordinarios para democratizar el acceso a la creación de flujos de trabajo. Un analista de negocios sin experiencia en programación puede tener un agente útil en funcionamiento a la hora del almuerzo. El límite existe, pero está lejos; los constructores visuales empiezan a dar problemas cuando los flujos de trabajo se ramifican en profundidad, cuando el estado debe mantenerse a lo largo de muchos pasos o cuando es necesario ajustar con precisión la latencia y el coste. Para muchos casos de uso internos, ese límite es suficiente.

Plataformas basadas en indicaciones

Claude Projects, los GPT personalizados de ChatGPT, Gemini Gems y los agentes de Microsoft Copilot le permiten crear soluciones redactando un conjunto detallado de instrucciones, adjuntando una base de conocimientos y concediendo acceso a un conjunto de herramientas cuidadosamente seleccionadas. No existe un lienzo visual; la “creación” consiste en una conversación. Estas plataformas resultan excelentes para agentes de conocimiento, asistentes de investigación, expertos internos y cualquier caso de uso en el que el valor resida en la calidad de la indicación y de los documentos, más que en la complejidad del flujo de trabajo. Además, son el punto de partida ideal para muchos ejecutivos, ya que no requieren ninguna intervención de ingeniería y producen algo realmente útil en una sola sesión.

Marcos basados en código

LangGraph, CrewAI, AutoGen y el ecosistema LangChain ofrecen a los equipos de ingeniería un control total sobre la orquestación, la memoria, el estado, las evaluaciones y la implementación. Además, es aquí donde se encuentran el SDK de agentes propio de Anthropic y los servicios de agentes de los principales proveedores de cloud. Las implementaciones basadas en código llevan más tiempo, requieren ingenieros y son la opción más adecuada cuando hay mucho en juego, las integraciones son profundas y el agente va a gestionar miles de solicitudes al día.

La realidad es que la mayoría de las empresas acaban utilizando las tres opciones. Los constructores visuales para la creación rápida de prototipos y la automatización sencilla de las tareas administrativas. Las plataformas basadas en indicaciones para casos de uso relacionados con el conocimiento y la asistencia que potencian a los equipos individuales. Los marcos basados en código para los agentes que realmente importan, aquellos que se encuentran en la ruta crítica de un proceso empresarial o de una interacción con el cliente. Considerar estos enfoques como bandos rivales en lugar de capas complementarias es un error habitual, que conduce a soluciones excesivamente complejas para problemas sencillos y a soluciones insuficientes para los problemas complejos.

La decisión rara vez se reduce a cuál es la mejor herramienta. Se trata de determinar qué herramienta se adapta mejor al caso de uso concreto que se le plantea.

¿Quién es capaz de construir uno?

Esta es la pregunta que los directivos se plantean con mayor frecuencia, normalmente en voz baja. La respuesta es realmente alentadora: prácticamente cualquiera, al menos al principio.

El acceso al trabajo con agentes se ha democratizado de una forma que muy pocos avances tecnológicos han logrado. Hace tres años, “crear un sistema de IA” requería científicos especializados en data, ingenieros de MLOps y un presupuesto. Hoy en día, un responsable financiero que conozca bien sus propios procesos puede crear un agente funcional en Claude o Copilot Studio sin escribir ni una sola línea de código. Hemos observado cómo esto se ha producido en todas las áreas de la empresa: equipos jurídicos que crean agentes de revisión de contratos, equipos de RR. HH. que desarrollan asistentes de incorporación, tasadores que crean herramientas de resumen de contratos de arrendamiento y equipos de ventas que desarrollan generadores de propuestas. La habilidad que importa no es la programación. Es la claridad de pensamiento respecto a la tarea: cómo se define “terminado”, qué necesita saber el agente y en qué momentos es necesario que una persona se mantenga al tanto.

Esto no significa que la ingeniería sea irrelevante. Significa que el papel de la ingeniería ha cambiado. En los mejores modelos operativos que observamos, las TI pasan de ser un «guardián» a un «facilitador», proporcionando las plataformas, las medidas de seguridad, los patrones de acceso y los marcos de evaluación dentro de los cuales los usuarios de negocio pueden desarrollar sus soluciones. La ingeniería construye la terminal y la pista de despegue; el negocio construye los aviones. Cuando algo que ha creado un usuario empresarial adquiere tal importancia que requiere un refuerzo de seguridad, la ingeniería se hace cargo de ello y lo lleva a producción. Esta es la auténtica democratización de la que se habla, y es una realidad.

Las implicaciones para los directivos son importantes. No es necesario contratar a un equipo de ingenieros especializados en IA para empezar. Lo que debe hacer es proporcionar a las personas más cercanas al trabajo las herramientas, la autorización y una breve formación. Los agentes que marcan la diferencia en los negocios de nuestros clientes casi nunca son los que se imaginan en la estrategia central. Son aquellos creados por las personas que realizan el trabajo, que saben exactamente dónde se producen los puntos de fricción.

Dónde está cobrando fuerza hoy en día el enfoque «agentic»

Cuando se habla del futuro de los agentes, se tiende a pasar por alto el presente, lo cual es una lástima, ya que el presente resulta más interesante de lo que la gente cree. Entre nuestra cartera de clientes —empresas internacionales, organismos del sector público y, en concreto, el sector inmobiliario—, hay una serie de patrones que, en la actualidad, generan valor de forma fiable. Merece la pena conocerlos.

Investigación y síntesis. Agentes que analizan documentos, fuentes web y sistemas internos para generar resúmenes estructurados. Se utilizan ampliamente para la inteligencia de mercado, el análisis de la competencia, la diligencia debida, la selección de inversiones y la revisión de políticas. Son una buena opción porque el trabajo requiere un alto grado de criterio, es repetitivo y admite la intervención de un revisor humano al final del proceso.

Tramitación de documentos. Extracción de datos de contratos de arrendamiento, revisión de contratos, tramitación de facturas, gestión de reclamaciones y KYC. En cualquier ámbito en el que sea necesario convertir documentos no estructurados en datos estructurados data, además de señalar aquellos casos que requieran la intervención de una persona. Se trata de la implementación en entorno de producción más habitual en los sectores regulados, incluido el inmobiliario.

Atención al cliente y al personal. Un triaje de primera línea que se encarga por completo de los casos sencillos y remite el resto con toda la información contextual adjunta. Si se lleva a cabo correctamente, estos agentes no sustituyen a las personas, sino que se aseguran de que estas solo se ocupen de los casos que realmente requieren su intervención.

Conocimientos internos. Agentes que se integran en los documentos, wikis, sistemas de gestión de incidencias y archivos de correo electrónico de una organización, y que responden a preguntas en lenguaje natural. Es aquí donde muchas empresas perciben el valor de forma más rápida y sencilla, y donde la gestión del cambio resulta más fluida, ya que el agente complementa los procesos en lugar de sustituirlos.

Generación de código. Merece la pena mencionarlo porque es el caso de uso que ha avanzado más rápidamente de todos. Los equipos de ingeniería son ahora, de forma habitual, entre un 30 y un 40% más productivos cuando utilizan herramientas de programación basada en agentes, y la diferencia sigue aumentando. Incluso los directivos que no pertenecen al ámbito de la ingeniería deberían prestar atención a este tema, ya que modifica la curva de costes de cualquier otro software que se desarrolle.

Cumplimiento normativo y garantía de calidad. Agentes que supervisan las infracciones, preparan las auditorías y detectan anomalías. Resultan especialmente relevantes ante el endurecimiento de la normativa en la UE, el Reino Unido y la región del Golfo.

¿Qué tienen en común los buenos casos de uso? Una heurística útil, que aplicamos con nuestros clientes: la tarea es lo suficientemente repetitiva como para que merezca la pena; requiere un grado de criterio tan elevado que la automatización tradicional ha fracasado; está lo suficientemente bien delimitada como para que se pueda describir el éxito en una sola frase; y admite una revisión con intervención humana en los casos que realmente importan. Si un caso de uso candidato cumple estos cuatro requisitos, probablemente merezca la pena ponerlo a prueba. Si cumple tres, merece la pena discutirlo. Si cumple uno, es una apuesta arriesgada.

Tres ejemplos resueltos

Las abstracciones solo resultan útiles hasta cierto punto. Para ilustrarlo con ejemplos concretos, a continuación se presentan tres casos reales extraídos de la forma en que, en la actualidad, se están implantando los agentes en distintos sectores.

Resumen del contrato de arrendamiento en el sector inmobiliario comercial

Una empresa inmobiliaria de tamaño medio cuenta con varios miles de contratos de arrendamiento en su cartera gestionada. Cada contrato de arrendamiento consta de entre cuarenta y noventa páginas de denso texto jurídico, almacenadas en formato PDF en un sistema de gestión documental. El equipo de gestión de activos necesita conocer, cuando sea necesario, el contenido de cada contrato: fechas de revisión del alquiler, cláusulas de rescisión, disposiciones sobre gastos de comunidad, restricciones de enajenación, obligaciones relacionadas con criterios ESG y cualquier cláusula inusual que pueda afectar a la valoración o al riesgo.

Históricamente, esta era una tarea propia de los asistentes jurídicos. Una nueva adquisición suponía seis semanas de extracción manual de datos antes de que el activo pudiera modelarse adecuadamente. Hoy en día, un agente de flujo de trabajo puede extraer los datos del mismo contrato de arrendamiento en quince minutos, estructurados según el esquema preferido del bufete, con indicaciones sobre cualquier aspecto inusual que deba revisar un perito colegiado. El tiempo de desarrollo de la primera versión fue de aproximadamente una semana en un generador visual. La preparación para su puesta en producción, la incorporación de registros de auditoría, las pruebas de evaluación con un corpus etiquetado de contratos de arrendamiento, la integración con el sistema de gestión documental y el registro de activos, así como el establecimiento de una vía de escalado minuciosa para las cláusulas ambiguas, llevó cuatro meses. La inversión se amortizó en menos de un año, y el trabajo que antes suponía un cuello de botella en cada transacción ya no lo es en ningún caso.

Servicio de asistencia informática interna para una multinacional

Una empresa de servicios a nivel mundial con quince mil empleados gestionaba un servicio de asistencia interna que se veía desbordado por la carga de trabajo. La mayoría de las incidencias eran variaciones de unas pocas docenas de patrones: restablecimiento de contraseñas, solicitudes de acceso a software, problemas con la VPN y consultas sobre el sistema de gastos. El equipo estimó que 60% de las incidencias podrían resolverse sin intervención humana si se dispusiera del contexto y las herramientas adecuadas.

Crearon un «agente de tareas», un único paso basado en un modelo de lenguaje grande (LLM) de alcance limitado integrado en la plataforma de gestión de incidencias existente, que leía cada incidencia recibida, intentaba resolverla directamente utilizando un pequeño conjunto de herramientas preaprobadas (el sistema de identidad, el catálogo de software y la API de gastos), y, a continuación, cerraba el ticket o lo derivaba a un agente humano con un borrador de respuesta y el contexto completo. Tiempo de desarrollo del prototipo inicial: dos días. Tiempo hasta la puesta en producción: tres meses, dedicados principalmente a los controles de acceso, los registros de auditoría y el ajuste de los umbrales de escalación para que no se pasara por alto nada importante. Resultado: el tiempo de resolución de las incidencias se redujo en un 70%, el equipo de primera línea pasó a dedicarse a tareas más interesantes y el agente gestiona ahora aproximadamente la mitad de todo el volumen de incidencias entrantes.

Estudio de inversiones en el Reino de Arabia Saudí en consonancia con la Visión 2030

Un vehículo de inversión vinculado al Estado deseaba evaluar de forma sistemática las oportunidades en función de las prioridades de la Visión 2030, los sectores señalados para la diversificación, los objetivos de desarrollo regional y los criterios ESG específicos del contexto saudí. El volumen de posibles objetivos, documentos informativos y documentos presentados ante las autoridades reguladoras era tal que ningún equipo humano podía revisarlos de forma exhaustiva.

En este caso, la solución adecuada fue un sistema multiagente. Un agente de investigación recopiló y estructuró la información sobre cada oportunidad a partir de documentos públicos, noticias y bases de datos con licencia data. Un agente de análisis evaluó la alineación con el marco «Visión 2030». Un agente de riesgos puso de manifiesto las preocupaciones normativas y de reputación. Un agente de redacción elaboró un informe estructurado para el comité de inversiones. Tiempo de desarrollo del prototipo: unas tres semanas, ya que la coordinación entre los distintos agentes requirió un trabajo de ingeniería propiamente dicho. Adaptación para la puesta en producción: seis meses, prestando especial atención a la residencia en el Reino (todo debía ejecutarse dentro del Reino), al manejo del idioma árabe y a un riguroso marco de evaluación comparativo con decisiones históricas. El sistema procesa ahora más oportunidades que el anterior equipo humano, y el comité recibe informes más exhaustivos y se limita a revisar únicamente las decisiones verdaderamente relevantes.

Lo que llama la atención en los tres casos es la relación entre ambos. En cada uno de ellos, la creación del prototipo llevó entre días y semanas. La implementación en producción, meses. Y en cada caso, no se habría obtenido el valor sin llevar a cabo ambas fases. El prototipo demuestra que funciona. La implementación en producción permite obtener el valor.

Elección de su modelo base

Tarde o temprano, a un directivo que impulse un programa de agentes se le planteará la siguiente pregunta: ¿qué modelo deberíamos utilizar? La respuesta sincera es “depende, y probablemente más de uno”, pero eso no resulta útil si no se explica con detalle. A continuación se ofrece una visión equilibrada de las principales opciones en 2026.

Servicios de modelos cerrados de Frontier

Claude (Anthropic). Se le considera generalmente el más sólido en razonamiento lógico, especialmente en lo que se refiere al uso de herramientas, contextos extensos, razonamientos complejos y juicios minuciosos. Sus modos de pensamiento ampliados le dan a Claude una ventaja en tareas complejas. Destaca por su capacidad para seguir instrucciones matizadas, lo cual es importante cuando el diseño incluye medidas de seguridad. Sólida postura empresarial, con posiciones claras en materia de formación en data, indemnización por propiedad intelectual y un conjunto de controles empresariales cada vez más maduro. Contras: los costes por token se sitúan en el extremo superior del nivel «frontier», y la disponibilidad fuera de las principales regiones de cloud ha sido históricamente inferior a la de los demás.

GPT (OpenAI). Es el hogar de los modelos de Frontier más extendidos y conocidos, con el ecosistema más completo de herramientas, integraciones y agentes preconfigurados. Los modelos de razonamiento de la serie «o» son competitivos en las tareas más complejas. Destaca en cuanto al código y destaca especialmente en la ergonomía para los desarrolladores. Inconvenientes: el comportamiento de los modelos ha variado notablemente entre las distintas versiones, lo que puede resultar problemático para los sistemas de producción en los que la coherencia es fundamental. La política de precios y la postura de la empresa han madurado, aunque algunas organizaciones siguen mostrándose cautelosas por motivos de confidencialidad. El contenido generado por GPT suele considerarse relativamente elocuente en comparación con el generado por Claude.

Gemini (Google). Excelente en tareas multimodales (el más destacado de los tres en cuanto al manejo nativo de imágenes, vídeo y audio) y perfectamente integrado en los ecosistemas de Google Workspace y Google Cloud. Gemini Flash resulta realmente económico a gran escala, lo que lo convierte en la opción predeterminada para cargas de trabajo de gran volumen y menor complejidad. Contras: la brecha en cuanto a la capacidad de razonamiento en tareas agentivas complejas se ha reducido, pero no se ha cerrado por completo en comparación con Claude y la serie «o».

Modelos de peso libre

Llama (Meta). La familia de fuentes de peso abierto más extendida, con un sólido apoyo del ecosistema y un rendimiento competitivo en los tamaños más grandes. La opción natural cuando se requiere el autoalojamiento para la residencia data, la previsibilidad de los costes en volúmenes muy elevados o por política de la organización. Contras: las condiciones de la licencia son viables, pero no tan permisivas como las licencias verdaderamente abiertas; el rendimiento en las tareas de razonamiento más complejas aún no alcanza los niveles más avanzados.

Mistral. Con sede en Europa, cuenta con modelos sólidos en múltiples tamaños y una política de licencias adaptada a las empresas. Es la opción ideal para los clientes europeos preocupados por la soberanía, y cada vez más eficaz en los tamaños más grandes. Los modelos más pequeños de Mistral destacan especialmente como capa principal en una implementación en ruta. Contras: un ecosistema más limitado que el de Llama, y una capacidad de razonamiento que aún se encuentra algo por detrás de los modelos cerrados de vanguardia.

Qwen (Alibaba). La familia con sede en China que más ha mejorado durante el último año. Sólida gestión multilingüe, especialmente en chino y árabe, y rendimiento competitivo en los volúmenes más grandes. De creciente relevancia para las organizaciones que operan en Asia y el Golfo. Contras: las consideraciones organizativas varían según la jurisdicción; algunas empresas no tendrán en cuenta los modelos de origen chino, independientemente de su capacidad.

El marco de decisión de Artefact

En la práctica, animamos a los clientes a plantearse dos aspectos: ¿qué grado de complejidad presenta la tarea? y ¿qué grado de sensibilidad tiene el data?

Figura 3. Marco de decisión de dos ejes para la elección de un modelo base.

Para tareas complejas en entornos no confidenciales data, los modelos cerrados de vanguardia de Claude, GPT o Gemini, a través de una API gestionada, constituyen casi siempre el punto de partida adecuado. La calidad del razonamiento es más importante que el coste o la sobrecarga de implementación.

Para tareas complejas relacionadas con datos sensibles —historiales de pacientes, transacciones financieras, información soberana—, un modelo de peso abierto autohospedado resulta cada vez más viable, especialmente con Llama en los tamaños más grandes. El rendimiento es suficiente para la mayoría de las tareas empresariales; la residencia y el control de los datos son imprescindibles.

Para tareas sencillas en entornos no confidenciales de data, el nivel de modelos ligeros; Claude Haiku, GPT-mini y Gemini Flash gestionan volúmenes enormes a un coste marginal. Aquí es donde se encuentran los agentes por correo electrónico, por documento y por transacción.

Para tareas sencillas en entornos sensibles como data, un modelo pequeño alojado en sus propios servidores —como Mistral Small, Qwen 2.5 o un modelo Llama ajustado— suele ser la solución más rentable.

La tarea es lo suficientemente sencilla como para que el modelo más pequeño resulte suficiente, y el autoaprendizaje se encarga de la sensibilidad.

Las implementaciones más sofisticadas actualmente distribuyen las solicitudes entre estos cuadrantes de forma dinámica. Cuando se recibe una solicitud de un usuario, un pequeño modelo de enrutamiento la clasifica y la envía al modelo más económico capaz de gestionarla. Así es como funciona realmente la economía a gran escala y cómo las empresas evitan tanto pagar de más por tareas rutinarias como prestar un servicio insuficiente en las tareas más complejas.

Una recomendación más: no se limite a sí mismo. Diseñe su plataforma de agentes de tal forma que el modelo sea sustituible. Es posible que los líderes de dentro de seis meses no sean los mismos que los de hoy; la capa del modelo debe ser un componente intercambiable, no un compromiso estructural. Si la propuesta de un proveedor dificulta esto, pregunte por qué.

Los obstáculos, tanto técnicos como organizativos

Esta es la sección que, si está leyendo este artículo con seriedad, probablemente debería leer dos veces. Los obstáculos para la implantación de agentes a nivel empresarial son bien conocidos por cualquiera que lo haya llevado a cabo realmente, y se dividen, a grandes rasgos, a partes iguales entre los de carácter técnico y los de carácter organizativo. Según nuestra experiencia, el aspecto organizativo es la parte más difícil y aquella en la que la mayoría de los equipos directivos invierten menos de lo necesario.

Figura 4. Los obstáculos que con mayor frecuencia frenan los programas agénicos.

Obstáculos técnicos

Calidad Data. La razón principal por la que los pilotos basados en agentes no logran escalar. Los agentes solo son tan eficaces como el data al que acceden. Los formatos inconsistentes, los registros duplicados, los campos que faltan y las fuentes data huérfanas los hacen fracasar rápidamente. Una auditoría del data antes —y no después— de un proyecto piloto es la mejora más económica que pueden llevar a cabo la mayoría de las organizaciones.

Expansión desordenada de data. Para la mayoría de las empresas, entre el 70 % y el 80 % de la información relevante se encuentra en archivos PDF, correos electrónicos, documentos escaneados, unidades compartidas y sitios de intranet. Los agentes pueden gestionar esta información, pero solo si se cuenta con la arquitectura de recuperación adecuada y la voluntad de invertir en su extracción, indexación y gestión.

Débil data governance. El historial, los controles de acceso, la residencia y las políticas de retención cobran una importancia fundamental cuando un agente puede leer y actuar en todo su entorno data. La mayoría de las empresas se dan cuenta de que su gobernanza es más débil de lo que pensaban la primera vez que un agente realiza una acción inesperada.

Integraciones de sistemas poco sólidas. Los sistemas ERP heredados, las API personalizadas y los sistemas que nunca se diseñaron para ser consultados mediante programación suponen un obstáculo. El Protocolo de Contexto de Modelos está resultando de gran ayuda en este sentido, pero los sistemas heredados siguen suponiendo un problema persistente.

No hay evaluaciones ni observabilidad. La señal de alarma más importante en la presentación de un proveedor es la ausencia de un marco de evaluación. Si no puede evaluar si el agente es adecuado, no podrá implementarlo. Hemos visto cómo organizaciones muy avanzadas han pasado por alto este aspecto y luego se han arrepentido.

Sorpresas en cuanto a costes y latencia. El consumo de tokens puede acumularse rápidamente. La latencia en los agentes con contextos extensos y que requieren un gran esfuerzo de razonamiento puede llegar a niveles que perjudiquen la experiencia del usuario. Ambos aspectos deben supervisarse desde el primer día, y no descubrirse en el cuarto mes.

Obstáculos organizativos

Titularidad poco clara. El trabajo de tipo «agente» se encuentra en una situación incómoda entre el departamento de TI, data y el ámbito empresarial. Sin un responsable claramente designado y sin un patrocinador con la autoridad política necesaria para zanjar los empates, los programas quedan estancados en un limbo de aprobaciones o se fragmentan en proyectos paralelos.

Incentivos desalineados. A las personas se les recompensa por el trabajo que realizan actualmente. Si un agente pone en peligro ese trabajo, las personas más indicadas para hacer que dicho agente resulte útil son precisamente las mismas que tienen más probabilidades de obstaculizarlo. Reconocerlo con franqueza es la mitad de la solución.

Incoherencia en el modelo operativo. La mayoría de las empresas se organizan en torno a proyectos con objetivos finales definidos. Los agentes son productos que requieren un ajuste, una evaluación y una mejora continuos. Intentar llevar a cabo el trabajo relacionado con los agentes mediante un modelo operativo de proyectos da lugar a implementaciones frágiles que se deterioran con el tiempo.

Deuda derivada de la gestión del cambio. Lo más difícil de la implantación de un agente no es crear el agente en sí, sino rediseñar el trabajo en torno a él. La mayoría de las organizaciones no han invertido en la capacidad de cambio necesaria para llevarlo a cabo adecuadamente.

Miedo al desplazamiento. La implantación se estanca cuando el personal teme que el agente esté ahí para sustituirlos. Las implantaciones más exitosas que observamos son claras y creíbles al respecto: el agente se encarga de las tareas más monótonas para que las personas puedan centrarse en aquellas partes del trabajo que requieren su criterio. No basta con decirlo; el comportamiento debe respaldarlo.

Bajo nivel de alfabetización en evaluaciones. A los directivos que no son capaces de evaluar de forma significativa si un agente está trabajando les resulta fácil dejarse convencer por demostraciones que no son extrapolables. Crear un vocabulario común —exactitud, precisión, recuperación, tasa de alucinaciones, tasa de escalación, coste por resolución— forma parte ahora de las funciones de cualquier directivo que supervise el trabajo de los agentes.

Si tuviéramos que señalar los dos obstáculos que merecen mayor atención por parte de la alta dirección, serían: data governance en el ámbito técnico y el modelo operativo en el ámbito organizativo. Son los que, si no se abordan, limitarán de forma imperceptible el valor que pueda obtener, por muy buenos que lleguen a ser los modelos.

Anatomía de una implementación de nivel empresarial

Una pregunta útil que conviene plantearse respecto a cualquier sistema de agentes antes de que entre en fase de producción es: ¿qué tendría que ocurrir para que me sintiera tranquilo si esto fallara públicamente? Porque, a gran escala, los agentes fallarán públicamente. La clave está en asegurarse de que, cuando eso ocurra, se pueda detectar, contener y recuperarse rápidamente.

Una implementación de nivel empresarial requiere una serie reducida de requisitos imprescindibles. Ninguno de ellos resulta especialmente interesante por sí solo; sin embargo, en conjunto marcan la diferencia entre algo que explicaría con gusto a un organismo regulador y algo que preferiría no tener que explicar.

Gestión de identidades y accesos. Cada acción de un agente debe ejecutarse bajo una identidad, con permisos heredados del usuario en cuyo nombre actúa. Los agentes que operan con amplios privilegios de cuenta de servicio suponen un riesgo de interrupción del servicio y un posible hallazgo de auditoría.

Registro de auditoría. Cada decisión, cada solicitud de asistencia técnica y cada escalación deben quedar registradas, ser inalterables y poder consultarse. No es opcional. Las autoridades reguladoras de los servicios financieros, la sanidad y, cada vez más, otros sectores regulados le preguntarán al respecto. Usted querrá que la respuesta sea “sí, aquí”.

Marco de evaluación. Un conjunto de pruebas etiquetadas con el que se evalúa al agente antes de cada lanzamiento, con umbrales claros que definen lo que se considera superado. Esta es la inversión de mayor valor que la mayoría de los equipos no aprovechan lo suficiente. Si su equipo no puede mostrarle sus evaluaciones, es que no ha desarrollado un agente de nivel empresarial.

Observabilidad. Visibilidad en tiempo real del rendimiento del agente en entorno de producción: tasa de éxito, latencia, coste por solicitud, tasa de escalación y desviación a lo largo del tiempo. Las mismas métricas que cabría esperar de cualquier servicio en producción, monitorizadas a nivel del agente.

Control de costes. Límites de gasto por usuario, por agente y por inquilino. Alertas. Limitación automática en caso de bucles sin control. El gasto de tokens sin controles es el equivalente, en el ámbito de los agentes, a una fuga de memoria.

Puntos de control con intervención humana. Las decisiones de gran trascendencia deben someterse a una revisión humana, en la que el agente exponga el contexto y formule una recomendación. El umbral concreto dependerá del caso de uso; sin embargo, la mera existencia de dicho umbral es innegociable.

Data: gobernanza y residencia. Políticas claras sobre qué data puede leer, escribir, conservar y transferir a través de las fronteras el agente. Esto reviste especial importancia si opera en la UE, el Reino Unido, los países del Golfo y otros regímenes con sus propias posiciones.

Comportamiento alternativo. ¿Qué ocurre cuando el modelo no está disponible, la respuesta no se puede analizar o falla la llamada a la herramienta? Los agentes de producción necesitan una degradación gradual, no un fallo silencioso ni un comportamiento inesperado.

Patrones de escalabilidad. La arquitectura debería poder gestionar un volumen 100 veces superior al del lanzamiento sin necesidad de cambiar de plataforma. Enrutamiento entre modelos, almacenamiento en caché, procesamiento asíncrono, ejecución basada en colas: las prácticas habituales de los sistemas distribuidos aplicadas a un nuevo sustrato.

Ninguna de estas deficiencias es inusual. Todas ellas suelen pasarse por alto en los sistemas de agentes que se han desarrollado con prisas y nunca se han reforzado adecuadamente. La razón por la que la brecha entre el prototipo y la producción es tan amplia es que esta lista representa precisamente esa brecha.

Guía práctica para el proceso de implementación

En todas las implementaciones de agentes que hemos llevado a cabo con nuestros clientes durante los últimos dos años, se ha puesto de manifiesto un patrón claro de cinco etapas. Definirlo abiertamente ayuda a los directivos a planificar los presupuestos, gestionar las expectativas y contar con las personas adecuadas en el momento oportuno.

Figura 5. Las cinco etapas de un despliegue agencial.

Fase 1: Descubrir. Identifique los casos de uso candidatos, evalúe su valor, analice el data que necesitarían y seleccione uno o dos para una primera prueba piloto. La disciplina en esta fase consiste en saber decir «no»: la mayoría de los casos de uso candidatos aún no están preparados, y empezar por el lugar equivocado es la razón más habitual por la que los programas pierden impulso. Los participantes: el patrocinador empresarial, los operadores que realizan el trabajo y un responsable de data.

Fase 2: Prototipo. Desarrolle un agente funcional para el caso de uso elegido, de principio a fin, en un plazo de unos días a unas semanas. Los constructores visuales o las plataformas basadas en indicaciones suelen ser las herramientas adecuadas en esta fase. El objetivo es demostrar que el caso de uso funciona en principio, no crear el sistema de producción. El equipo: un pequeño equipo de desarrollo, usuarios de negocio para recabar opiniones y el equipo de ingeniería para asesorar sobre el camino hacia la producción.

Fase 3: Endurecimiento. La fase más larga y a la que se suele destinar menos presupuesto. Se debe crear el entorno de evaluación, añadir controles de acceso, implementar la observabilidad, determinar los puntos de control con intervención humana y realizar pruebas previas a la producción. La mayoría de las empresas se estancan en esta fase, ya que el trabajo no resulta atractivo y el prototipo ya tiene un aspecto impresionante. Los departamentos implicados: ingeniería, seguridad, riesgos y cumplimiento normativo, y gestión del cambio.

Fase 4: Implementación. Implemente la solución entre los usuarios piloto, supervise atentamente las métricas y realice ajustes en función del uso real. Planifique la gestión del cambio; forme a los usuarios, establezca las expectativas y cree un ciclo de retroalimentación. La mayoría de las implementaciones requieren entre tres y seis semanas de supervisión minuciosa antes de proceder a una implantación más amplia. Los responsables: el departamento de operaciones, el de gestión del cambio y RR. HH., así como el patrocinador empresarial original.

Etapa 5: Ampliación. Ampliar el agente a poblaciones más amplias, identificar patrones y componentes reutilizables, y crear el centro de excelencia que dará soporte a los casos de uso segundo, tercero y cuarto. Es aquí donde la cuestión del modelo operativo cobra especial relevancia: ¿cómo gestiona realmente la organización un conjunto de agentes a lo largo del tiempo? Los participantes: el patrocinador ejecutivo, los futuros responsables de IA y el responsable del modelo operativo.

En la actualidad, la mayoría de las empresas cuentan con varios proyectos piloto en la fase 2 y muy pocos sistemas en las fases 4 o 5. La ventaja competitiva en los próximos dos años recaerá de forma desproporcionada en aquellas organizaciones que aprendan a pasar sin contratiempos de la fase 3 a la fase 5.

Perspectivas a corto y medio plazo

¿Cómo será el panorama de la agencia dentro de 12 a 36 meses? Ya se vislumbran cuatro cambios que conviene tener en cuenta a la hora de planificar.

Los sistemas multiagente se están convirtiendo en la norma para las tareas complejas. Hoy en día, la tecnología multiagente representa la vanguardia. Para 2027, será la arquitectura por defecto para cualquier flujo de trabajo basado en agentes que no sea trivial. Las herramientas de orquestación están madurando rápidamente, y el coste de ejecutar múltiples agentes especializados es ahora lo suficientemente bajo como para que la simplicidad de ingeniería que supone “un único agente grande” ya no resulte justificada desde el punto de vista económico. Las empresas que hayan invertido en marcos de evaluación y observabilidad se adaptarán a esta tendencia sin problemas. Las que no lo hayan hecho tendrán dificultades.

Mercados de agentes y componentes reutilizables. La situación actual, en la que cada empresa desarrolla todos sus agentes desde cero, es transitoria. Prevemos un cambio significativo hacia mercados de agentes ya desarrollados y componentes reutilizables, tanto suministrados por proveedores como propios de las empresas. En las grandes empresas ya está surgiendo el equivalente interno a una tienda de aplicaciones privada. Para los ejecutivos, esto modifica la disyuntiva entre «desarrollar o comprar», que para 2027 se parecerá más a «desarrollar o componer».

Minería de procesos basada en agentes. Los proveedores de minería de procesos están incorporando rápidamente capacidades basadas en agentes, mientras que el descubrimiento de procesos nativo de la IA está surgiendo desde otra perspectiva. Los agentes combinados, capaces de mapear sus procesos, identificar oportunidades y, a continuación, implementar los flujos de trabajo resultantes, se convertirán en una categoría cada vez más relevante. Analice con cautela las propuestas actuales de los proveedores en este ámbito; la tecnología avanza rápidamente y el riesgo de dependencia es real.

Se endurecen las normas. Los requisitos para los sistemas de alto riesgo de la Ley de IA de la UE entrarán en vigor de forma progresiva a lo largo de 2026 y 2027. El Reino Unido está adoptando un enfoque más sectorial, pero los servicios financieros, la asistencia sanitaria y las infraestructuras críticas se incluyen en su ámbito de aplicación. La SDAIA de Arabia Saudí y la Oficina de IA de los Emiratos Árabes Unidos han publicado marcos normativos que se convertirán en requisitos vinculantes. La Ley Básica de IA de Corea del Sur entró en vigor en enero de 2026. En EE. UU. existe un mosaico cambiante de legislaciones estatales. Y los sectores están respondiendo con directrices actualizadas: la RICS está actualizando sus directrices para el sector inmobiliario; la MAS de Singapur ha publicado principios y metodologías específicos para la IA en el ámbito financiero; y las aseguradoras preguntan ahora a los bufetes de abogados y a las firmas de contabilidad, en el momento de la renovación, si cuentan con políticas de uso de la IA. La carga que supone el cumplimiento normativo está aumentando, pero también se está aclarando en qué consiste dicho cumplimiento. Planifíquese para ello; no se deje sorprender por ello.

El aspecto estratégico más importante que deben interiorizar los directivos es que los modelos base seguirán convirtiéndose en un producto básico. La ventaja competitiva no residirá ahí. Residirá en el modelo data propio al que tenga acceso, en los flujos de trabajo que haya rediseñado en torno a la capacidad de agencia y en la infraestructura de evaluación que haya creado y que le permita implementar mejoras más rápidamente que sus competidores. Las organizaciones que inviertan ahora en estos tres aspectos obtendrán una ventaja acumulativa; las que apuesten por que un modelo concreto resulte ganador, no.

La tentación de esperar a que las cosas se estabilicen es comprensible. Pero también resulta costosa. El coste de empezar ahora consiste, en su mayor parte, en el coste de los errores; el coste de esperar dos años es el de quedarse estructuralmente por detrás de los competidores que han aprendido sobre la marcha.

Una respuesta mesurada al titular

Volviendo al titular: ¿es realmente posible crear un agente de IA de nivel empresarial en tan solo unas horas?

Se puede crear un agente en unas pocas horas. Se puede crear algo útil en unos pocos días. Se puede crear algo realmente bueno en unas pocas semanas. Pero un sistema de nivel empresarial —del tipo que presentaría con total confianza a sus clientes más importantes, a sus organismos reguladores y a su consejo de administración— requiere meses de trabajo minucioso, incluso con las mejores herramientas. Y esa brecha no se está reduciendo tan rápidamente como sugieren los titulares. En todo caso, se está ampliando, ya que el listón de lo que significa “de nivel empresarial” se eleva en paralelo a las capacidades de los modelos subyacentes.

La buena noticia es que el coste de averiguarlo se ha reducido prácticamente a cero. Tres medidas que cualquier directivo puede poner en práctica la próxima semana, sin necesidad de aprobación presupuestaria, sin un comité directivo y sin comprometerse a nada estratégico.

En primer lugar, elija una tarea repetitiva, que requiera tomar muchas decisiones y que esté bien delimitada dentro de su propio trabajo. Cree un agente básico para ella en Claude, ChatGPT, Gemini o Copilot Studio. Úselo durante quince días. Aprenderá más en esas dos semanas que con cualquier cantidad de presentaciones de diapositivas.

En segundo lugar, analice un proceso de su empresa a la luz de la heurística de cuatro partes mencionada anteriormente: repetitivo, que requiere un alto grado de criterio, delimitado y susceptible de revisión humana. Los procesos que resulten de este análisis son aquellos en los que se encuentran sus verdaderas oportunidades.

En tercer lugar, plantee a su equipo una única pregunta: ¿cuál es nuestro marco de evaluación? Si no pueden responder con claridad, ese será su punto de partida.

Las empresas que logren hacerlo bien en los próximos dieciocho meses no serán aquellas que hayan creado las demostraciones más ingeniosas. Serán aquellas que hayan aprendido, con rapidez y honestidad, a salvar la distancia que separa un agente que funciona de uno que realmente funciona.

Casos prácticos

Una solución de creación visual para analistas del sector inmobiliario comercial

Artefact ayudó a una empresa del sector inmobiliario comercial (CRE) a alcanzar la autosuficiencia estratégica en el desarrollo de «Task Agents» mediante sesiones de formación, tutoría y programación en pareja para su equipo interno de analistas, al tiempo que dirigió la entrega de tres «Task Agents» operativos. La arquitectura de los agentes se limitó a Claude (servicio de modelo base) y Power Automate (orquestación, memoria, herramientas y medidas de seguridad), de modo que los agentes pudieran basarse, en líneas generales, en el mismo ecosistema de herramientas al que el equipo interno estaba acostumbrado y que este fuera capaz de mantener junto con su tecnología existente.

De este modo, a los agentes se les atribuyeron algunos atributos de un servicio de producción, pero no otros, entre los que se incluyen el registro de auditoría, la observabilidad y la escalabilidad. No obstante, en poco tiempo, el CRE adoptó un enfoque conciso pero eficaz en materia de data governance y residencia, puntos de control con intervención humana y gestión de la identificación y el acceso, junto con procesos de evaluación y procedimientos de administración básicos, lo que le permitió encaminarse hacia la consecución de mejoras significativas en la eficiencia.

Innovación en agentes de flujo de trabajo para una empresa de capital riesgo internacional

Artefact ha desarrollado un prototipo de ‘agente de flujo de trabajo’ implementado en las ‘habilidades’ de Claude, que se ha convertido en un «conector» de Claude de alto rendimiento; esto representa el uso de MCP para pasar de definir una tarea de IA exclusivamente en lenguaje natural a definirla como una combinación de herramientas de IA de alto rendimiento. La diferencia clave que convierte a la solución en un «Workflow Agent» y no simplemente en un «Task Agent» es la aplicación de un LLM principal para gestionar la secuencia de llamadas a las herramientas, además de la invocación de LLM secundarios para llevar a cabo las operaciones de dichas herramientas.

La introducción del patrón «Claude Connector» junto con una pila de Azure ya existente generó un nuevo requisito para dar soporte al tráfico de entrada de red y al acceso data. En aquellas organizaciones en las que los servicios comunes de este tipo se gestionan con éxito como servicios compartidos, observamos que el tiempo necesario para la implementación de nuevos servicios en producción se reduce hasta tres veces con cada nueva puesta en marcha.

Chris de Gruben Es director sénior en Artefact, donde dirige el sector inmobiliario en todo el Reino Unido y la Unión Europea. Colabora estrechamente con clientes de los sectores público y privado en todo el Reino Unido, Europa y la región del Golfo.

Oliver Richardson es director sénior de aprendizaje automático en Artefact y lleva más de 20 años ayudando a organizaciones de los sectores financiero, comercial y público a implementar productos de IA y aprendizaje automático de última generación.

Artefact colabora con empresas para diseñar, desarrollar y gestionar sistemas de inteligencia artificial a gran escala, desde la primera fase piloto hasta la implantación a nivel empresarial. Si actualmente se enfrenta al reto de salvar la brecha entre el prototipo y la fase de producción, estaremos encantados de intercambiar opiniones con usted.