Del experimento con IA a un servicio confiable

15 min de lectura

El experimento útil merece un futuro

Un ejemplo ilustrativo: una empleada de operaciones de un pequeño mayorista dedica cada mañana a leer correos de clientes, buscar códigos de producto y preparar borradores de pedidos. El sistema espera campos ordenados. Los clientes prefieren frases, fotografías y los nombres de siempre.

Prueba ChatGPT y luego le da algunos ejemplos a Claude Cowork. Tras unas correcciones, obtiene borradores de pedidos útiles. Los revisa. Ahorra tiempo. Un compañero pregunta si también puede usarlo.

Es una buena noticia. Alguien cercano al trabajo ha encontrado cómo mejorarlo, y el experimento revela más que cualquier reunión sobre transformación digital.

Después, los borradores se convierten en la forma habitual de recibir pedidos en la empresa. Los demás dejan de hacer la preparación anterior. Su jefe da por hecho que el asistente funcionará cada mañana.

Nadie decide que ella ahora opera un servicio del negocio. Al parecer, esa responsabilidad venía de regalo con su curiosidad.

El CTO tiene aquí una oportunidad útil: ayudar a convertir el valor demostrado en algo de lo que la empresa pueda depender. Eso exige trabajar con ella, conservar lo aprendido y elegir una solución que el negocio pueda mantener.

Los agentes en la nube son reales. Sus límites difieren.

Las ofertas ya van mucho más allá de una ventana de chat que desaparece al cerrar la computadora. Pueden usar herramientas, conservar contexto y continuar en segundo plano con el trabajo delegado. Pero «agente en la nube» abarca configuraciones muy distintas.

La siguiente comparación se basa en documentación de los proveedores revisada el 15 de octubre de 2026. Describe capacidades documentadas, no resultados de pruebas propias de confiabilidad. La disponibilidad puede variar según la cuenta, el plan, la región y los ajustes del administrador. Tener derecho a usarlo no significa que esté habilitado.

Oferta	Ejecución y persistencia	Integraciones, permisos y controles	Acceso documentado
OpenAI Dots	Computadora y navegador propios en la nube, contexto guardado y responsabilidades continuas. El trabajo en la nube sigue aunque los dispositivos estén apagados.	Los plugins conectados conservan sus permisos; el acceso local requiere una computadora conectada y en línea. Los administradores del espacio de trabajo controlan las capacidades y las acciones de las aplicaciones.	Despliegue gradual para cuentas elegibles; hay que confirmar plan, región y acceso al espacio de trabajo. Los administradores de Enterprise conceden acceso mediante sus permisos. Véanse Dots y los controles del espacio de trabajo.
Grok Bot	Una computadora persistente por usuario en la nube de Cursor. Todos los bots de ese usuario comparten archivos y sesiones de navegador.	Shell, navegador, uso de la computadora y conectores permitidos. Los controles de red, el registro de acciones y las políticas de aprobación obligatorias requieren Enterprise.	La administración de equipos está documentada para Cursor Teams y Enterprise, con controles distintos. Hay que confirmar el acceso de la cuenta prevista. Véanse arquitectura y administración.
Meta Muse	Máquina virtual dedicada; el trabajo continúa después de cerrar la aplicación. El contexto permite dar seguimiento a objetivos continuos.	Conectores empresariales para cuentas de Meta y herramientas de terceros. Meta afirma que publicar, enviar y gastar requieren aprobación.	El anuncio señala disponibilidad en Estados Unidos y Canadá; las funciones y los conectores para pequeños negocios se añadieron en septiembre. Véanse Muse y Muse for Small Business.
Claude Cowork	Las sesiones en la nube guardan el trabajo y admiten tareas programadas. Desde el 6 de octubre, las tareas nuevas de Pro y Max se ejecutan en la nube; las tareas locales anteriores siguen siendo locales.	Conectores, skills y plugins. Las carpetas locales requieren que la aplicación de escritorio esté abierta y conectada. Los responsables de Team/Enterprise disponen de controles de supervisión.	Sesiones en la nube para Pro/Max; Cowork en la nube está en beta para Team/Enterprise. También se está desplegando una experiencia unificada de chat y tareas bajo el nombre Claude. Véanse disponibilidad actual y medidas de protección del acceso.
Perplexity Computer	Flujos en la nube que continúan en segundo plano; tareas recurrentes y varios modelos permiten trabajos más largos.	Conectores configurados y skills reutilizables; los administradores empresariales controlan usuarios y conectores. El proveedor distingue su entorno de desarrollo del alojamiento en producción.	Enterprise Pro y Enterprise Max están documentados en las preguntas frecuentes del taller de Computer.
Manus Cloud Computer	Máquina virtual Ubuntu persistente: archivos, herramientas instaladas y procesos se conservan entre sesiones. Los entornos aislados de las tareas habituales de Manus son temporales.	Aplicaciones de línea de comandos, scripts y bots pueden ejecutarse de forma continua. La descripción no establece un modelo de aprobaciones o auditoría para toda la empresa; hay que comprobarlo por separado.	Requiere un plan activo; Manus puede asignar el entorno persistente cuando una tarea lo necesita. Véase Cloud Computer.
MiniMax MaxClaw	OpenClaw alojado por el proveedor, con memoria a largo plazo, almacenamiento en la nube y trabajo recurrente.	Herramientas de navegador y archivos, además de integraciones de mensajería como Telegram, Discord y Slack. La página del producto no demuestra que existan controles empresariales de permisos.	Disponible mediante MiniMax Agent, con despliegue en un clic y actualizaciones gestionadas por el proveedor. Véase MaxClaw.
Kimi Claw	OpenClaw alojado, con memoria a largo plazo; también permite vincular una instancia existente en el propio dispositivo.	Integraciones con canales de chat y colaboración en grupo. Los propietarios del grupo controlan miembros y visibilidad; esos controles no establecen qué permiten los sistemas conectados.	El despliegue alojado requiere Allegretto o superior. Véanse Kimi Claw y controles de grupo.
OpenClaw, alojamiento propio	El usuario elige y mantiene el servidor, el almacenamiento, el acceso a modelos y las integraciones. La persistencia depende de ese despliegue.	Hay que configurar las políticas de herramientas, los controles de acceso y el aislamiento. Cada gateway presupone un único ámbito de confianza; no aísla a usuarios que desconfían entre sí.	Disponible para despliegue propio; operarlo es responsabilidad del usuario. Véase el modelo de seguridad.
Microsoft Copilot Cowork	Trabajo de varios pasos en Microsoft 365 y tareas recurrentes en un entorno aislado. Los archivos resultantes se conservan en OneDrive/SharePoint.	Actúa con los permisos del usuario; aprobaciones, controles de plugins, registros de auditoría y límites de uso se gestionan desde la administración empresarial. Algunas tareas de navegador usan el Edge local del usuario.	Disponibilidad general; las políticas de gasto conceden acceso y habilitan la facturación por uso. Véanse administración y preguntas frecuentes.

MaxClaw y Kimi describen expresamente ofertas basadas en OpenClaw. Eso no demuestra que Dots, Muse, Cowork o los demás compartan esa arquitectura. Una delegación parecida no prueba que funcionen igual por dentro.

Gemini Enterprise pertenece a otra comparación: una plataforma organizativa para descubrir, crear, desplegar y gobernar agentes, con capacidades que dependen de la edición. Salesforce Agentforce combina el razonamiento del modelo con flujos explícitos, código y acciones de API dentro de procesos de negocio. Ninguno es simplemente otra computadora personal en la nube con un nombre nuevo.

Estas diferencias importan al elegir una herramienta. No resuelven quién se hace cargo del proceso de pedidos. Un proveedor puede mantener la computadora mientras la empresa sigue siendo responsable de las reglas, las cuentas conectadas, las excepciones y las consecuencias.

La macro de oficina aprendió a leer el correo

Los libros de Excel, las macros de VBA, las bases de datos de Access, los pequeños scripts, los flujos de bajo código y la automatización robótica de procesos comenzaron con alguna variante de «esto tiene que poder hacerse mejor». Muchas veces era cierto. Quien hacía el trabajo veía un problema al que la lista oficial de proyectos aún no había llegado.

El patrón de adopción es conocido. Las capacidades son distintas.

Un agente puede interpretar un correo que no encaja en una plantilla, investigar una descripción de producto desconocida, comparar información de varios sistemas y decidir qué herramienta probar después. El contexto persistente le ayuda a conservar decisiones anteriores. Un acceso más amplio a herramientas le permite actuar más allá de la hoja de cálculo original.

La ejecución en la nube y las tareas programadas son anteriores a esta ola de agentes. Office Scripts y Power Automate ya permiten trabajar con hojas de cálculo mediante horarios o eventos, sin que alguien tenga que mantener Excel abierto. El cambio significativo es que el modelo interpreta entradas y selecciona acciones donde el flujo anterior necesitaba instrucciones explícitas para cada alternativa.

Eso sirve cuando hace falta interpretar. También es una pésima razón para volver negociables las reglas establecidas.

En nuestro ejemplo de pedidos, leer «otra caja como la de la vez pasada» puede exigir interpretación y una pregunta. Aplicar el precio acordado, comprobar la cuenta del cliente y evitar un pedido duplicado deben seguir reglas explícitas. El agente puede llamar a herramientas que las hagan cumplir. No necesita inventar de nuevo el procedimiento de pedidos.

El código determinista puede tener errores. Las herramientas elegidas por un agente pueden ejecutar código determinista. La distinción útil está en dónde se permite decidir según el contexto y dónde el negocio necesita una decisión repetible que pueda poner a prueba.

La lección de modernizar soluciones antiguas en VBA sigue vigente: descubrir el comportamiento real, examinar las excepciones y convertir los ejemplos importantes en comprobaciones ejecutables. Un prompt no exime al proceso de ese trabajo.

El software a medida se ha vuelto más accesible

Hay otro cambio económico detrás de los anuncios de agentes en la nube. La IA también puede ayudar a desarrolladores experimentados a construir más rápido el software que hace el trabajo.

Para un proceso bien delimitado, con reglas conocidas e integraciones utilizables, la IA puede reducir el esfuerzo de escribir y revisar código. Hay que comprobar ese ahorro con una pequeña parte funcional del proceso real antes de prometer una fecha. Los requisitos poco claros, los sistemas inaccesibles, las migraciones y las decisiones organizativas no se vuelven pequeños porque el modelo teclee rápido.

Eso justifica revisar una vieja suposición: que comprar una herramienta de propósito general necesariamente sale más barato que construir un pequeño servicio para la tarea concreta.

Para el mayorista, el servicio podría leer una solicitud entrante, extraer una propuesta de pedido, validar los códigos de producto contra el catálogo, aplicar las reglas de precios acordadas y presentar los casos ambiguos a una persona. Los pedidos aprobados entrarían al sistema mediante una integración controlada. El servicio dejaría constancia de lo ocurrido.

Un modelo puede seguir interpretando el lenguaje. El proceso que lo rodea puede tener una secuencia definida, permisos explícitos y pruebas para las excepciones conocidas. Si el mismo mensaje llega dos veces, el segundo intento no debe crear otro pedido. Si la cuenta del cliente está bloqueada, el servicio debe detenerse antes de enviar nada.

Estas decisiones pasan a formar parte del sistema, en lugar de ser instrucciones que alguien espera que el agente recuerde en cada ejecución. La empresa puede volver a comprobarlas cuando cambie la implementación.

Hay costos en ambos lados. Las ejecuciones del agente consumen recursos y tiempo de revisión. El software a medida necesita alojamiento, actualizaciones de dependencias, mantenimiento de integraciones, supervisión y trabajo de recuperación. Junto al desarrollo inicial hay que comparar los costos recurrentes y las consecuencias de los fallos.

Construir más barato vuelve la elección más interesante. No hace que ninguna de las opciones se mantenga sola.

La curiosidad no es un contrato de operación

Home Assistant ofrece una analogía útil. Experimentar con la automatización de la casa puede ser satisfactorio. Uno aprende qué hace un dispositivo, ajusta una rutina y arregla algo cuando tiene tiempo. Luego otras personas dependen de que la calefacción, las luces o la alarma funcionen mientras uno está ocupado en su trabajo habitual.

La dependencia cambia la tarea. Saber qué habitación necesita calefacción no enseña automáticamente a diagnosticar todos los fallos de integración. Tener interés no significa haber aceptado dar soporte cada vez que algo se rompe.

En el trabajo ocurre lo mismo. La empleada de operaciones sabe por qué importa un pedido, qué descripciones de producto son ambiguas y qué clientes tienen condiciones especiales. Ese conocimiento merece un lugar en la solución. Puede que ella no tenga ni el tiempo ni la experiencia para evaluar una estrategia de reintentos, mantener la autenticación o recuperar una transacción parcialmente completada.

Volvamos al ejemplo:

• El sistema acepta un pedido, pero la conexión se corta antes de que el asistente registre el éxito. Un reintento puede crear un duplicado.
• Una sesión guardada caduca. La ejecución programada espera un nuevo inicio de sesión mientras los compañeros creen que los pedidos ya están listos.
• Un precio cambia entre la preparación y el envío del pedido. Alguien debe decidir cuál corresponde aplicar.
• Varias solicitudes terminan y una falla. Reiniciar el lote completo puede repetir trabajo ya realizado.
• La empleada que creó la automatización se marcha. Su reemplazo hereda el proceso de negocio, pero la automatización sigue funcionando bajo la cuenta de ella.

Son preguntas operativas normales. Exigen un comportamiento definido y alguien que pueda actuar cuando no se cumpla.

En una pyme, el primer problema visible puede ser simplemente la responsabilidad: todos lo usan y nadie tiene tiempo para mantenerlo. En una empresa mayor, las cuentas y las integraciones sin administrar también se convierten en TI en la sombra. La versión preliminar pública de Shadow AI de Microsoft permite detectar agentes no administrados en dispositivos gestionados y bloquear algunos de ellos. El problema ya llegó a la consola de administración.

Culpar a la empleada sería equivocarse de problema. Ella demostró una mejora útil. La organización debe decidir cómo sostener aquello de lo que eligió depender.

Llevar el experimento al CTO y a los desarrolladores

Una petición abstracta de «procesamiento de pedidos con IA» deja mucho por adivinar. Una empleada que puede mostrar diez ejemplos reales, tres correcciones y el punto donde el asistente se confunde aporta algo mucho mejor.

El experimento se convierte en algo que todos pueden examinar. ¿Qué entendió correctamente? ¿Qué reparó la empleada sin decirlo? ¿Qué decisiones salieron de las políticas de la empresa y cuáles se inventó el modelo? ¿Dónde dependía el aparente éxito de que ella estuviera presente?

Ese es un punto de partida productivo para nuestro trabajo de consultoría: sentarnos con la empleada y el CTO, seguir el proceso real y tomar juntos las decisiones necesarias. Incorporar a desarrolladores y proveedores donde haga falta su conocimiento. La empleada aporta experiencia del proceso; la experiencia técnica ayuda a elegir una implementación mantenible y pruebas que demuestren que funciona.

Desarrollar Nilo Assistant vuelve tangibles esas responsabilidades una y otra vez. Un servicio que envía un correo necesita saber qué ocurrió si se detiene después de que el proveedor de correo aceptó el mensaje. Registrar el éxito, resolver un resultado incierto y evitar un segundo envío forman parte de la función. Una conversación amable no puede resolverlo por sí sola.

Las mismas preguntas corresponden al experimento de la empleada. Primero hay que aclarar el qué y después pulir la solución: qué debe pasar, qué no debe pasar nunca, qué necesita aprobación y qué debe ocurrir después de una interrupción.

Convertir ejemplos y excepciones en pruebas. Estabilizar las integraciones. Comprobar los permisos donde se ejecutan las acciones. Hacer visibles los fallos para alguien que pueda responder. Decidir qué partes pueden seguir dirigidas por agentes y cuáles necesitan código explícito o un flujo controlado.

El CTO debe participar en esas decisiones. La ayuda externa fortalece al equipo existente cuando conecta la intención del negocio, el comportamiento del software, los límites de los proveedores y la operación. Pasar por encima del CTO solo aplaza la discusión sobre responsabilidades hasta el próximo incidente.

Algunos clientes necesitan ayuda para construir el servicio. Otros también necesitan a alguien que lo opere. Son compromisos distintos, con trabajo y costos diferentes. Hay que dejar claros ambos, incluyendo quién cambia las reglas y quién responde cuando falla una dependencia.

Terminado significa que alguien puede depender de él

«Terminado» es una palabra incómoda en software. Muchos la entienden como permiso para dejar de prestar atención. Un servicio del negocio necesita un significado más útil: apto para un uso confiable, con responsabilidad continua.

Para el servicio de pedidos, eso significa que el comportamiento acordado y las excepciones son explícitos. Las promesas importantes tienen comprobaciones ejecutables. Quien lo opera puede ver el trabajo fallido o de resultado incierto, distinguirlo del completado y recuperarlo sin volver a enviar todo a ciegas. Las integraciones y las credenciales tienen responsables de mantenimiento. Alguien además de la entusiasta original puede operar el servicio.

La alternativa en caso de fallo también importa. Si la automatización no está disponible, ¿quién prepara los pedidos y cómo evita la empresa procesar dos veces la misma solicitud al reanudar el servicio? «Lo haremos manualmente» necesita un procedimiento real, no un gesto tranquilizador hacia el departamento de operaciones.

Estas exigencias se aplican tanto si el resultado funciona dentro del agente de un proveedor como en un sistema de alojamiento propio o en una pequeña aplicación a medida. Una plataforma administrada puede aportar controles útiles. La empresa sigue teniendo que decidir el comportamiento y financiar la operación.

Los agentes de IA te convierten en una empresa de software planteó la responsabilidad. La oportunidad práctica ahora es hacerla asequible: usar experimentos para descubrir valor, aprovechar el desarrollo asistido por IA para construir la solución adecuada y establecer cómo se va a operar.

Hay que apoyar a la empleada curiosa. Incorporar al CTO y a desarrolladores experimentados antes de que el experimento se convierta en un segundo empleo que nadie reconoce.

La IA abarata la creación de software útil. Convertirlo en un servicio sigue siendo trabajo de alguien.