Los agentes de inteligencia artificial pueden escribir código, consultar sistemas y encadenar acciones durante una misma tarea. Para una organización, esa capacidad abre una pregunta muy concreta: ¿cómo convertirla en trabajo útil que se pueda financiar, supervisar y aceptar con confianza? Las novedades de esta semana permiten mirar esa pregunta desde varios ángulos: consumo, aislamiento, evaluación, operación en la nube y preparación de las personas.
Accenture vuelve a poner el presupuesto sobre la mesa. Perplexity abre la infraestructura de aislamiento de sus agentes. Microsoft amplía las herramientas para operar Azure y GitHub explora la colaboración entre modelos. En investigación, Harness² busca mejorar el sistema que rodea al modelo, mientras otro estudio examina cómo el aprendizaje visual puede transferirse a respuestas textuales. También aparecen oportunidades para llevar agentes a los canales de comunicación y a los sistemas de diseño.
Mi lectura desde la formación tecnológica, la ciberseguridad y GRC —gobernanza, riesgo y cumplimiento— es que debemos conectar esas piezas. La autonomía necesita presupuesto, autoridad delimitada y evidencia del resultado. Este análisis distingue los hechos publicados de mis propuestas de aplicación empresarial. Las fuentes se revisaron al 20 de octubre de 2026.
1. Accenture y Claude: el presupuesto forma parte del diseño
404 Media informó el 15 de octubre que Accenture limitó a 29 dólares mensuales por persona el gasto en Claude que financiaría de forma centralizada, después de consumos individuales reportados de hasta 1.000 dólares. La cobertura de la medida señala que el consumo adicional debe imputarse a proyectos o equipos. Se trata de una política interna reportada periodísticamente, no de una nueva tarifa de Claude ni de un límite universal para todos sus clientes. Fuente: investigación de 404 Media y cobertura de The Next Web.
La discusión empresarial debe partir de la unidad de trabajo. Mil dólares pueden representar un gasto injustificado o una inversión razonable; para decidirlo necesitamos saber qué se produjo, cuánto esfuerzo humano requirió y si el resultado fue aceptado. Una cifra aislada de consumo no permite evaluar productividad.
En un piloto propondría registrar costo por tarea completada, tiempo de revisión, reintentos y fallos. Si un agente prepara informes, contarían los informes aprobados por su responsable. Si modifica software, contarían los cambios que cumplen los criterios de aceptación. Esa medición también ayuda a detectar tareas en las que un modelo menos costoso o un flujo más corto produce resultados suficientes.
El presupuesto debería distinguir exploración, operación recurrente y excepciones justificadas. Cada proyecto necesita un responsable del gasto y alertas antes de agotar su asignación. También conviene definir qué sucede al llegar al límite: guardar el avance, reducir el alcance o solicitar una ampliación. Cortar una tarea sin preservar su estado puede desperdiciar lo ya invertido. La disciplina financiera funciona mejor cuando está incorporada al flujo de trabajo.
2. SPACE: aislar el cómputo y controlar la red son pruebas diferentes
Perplexity publicó como código abierto SPACE, la plataforma de aislamiento utilizada por Computer. Su arquitectura utiliza microVM basadas en Firecracker y mantiene controles de red y credenciales fuera del entorno que ejecuta el agente. La apertura permite inspeccionar esa implementación y adaptarla. Fuente: anuncio de Perplexity.
La evaluación publicada requiere una lectura precisa: nueve modelos participaron en las pruebas y no se observó un escape desde la máquina virtual hacia el anfitrión en 108 ejecuciones. Sin embargo, antes de las correcciones hubo evasiones de la política de red en 11 de 54 ejecuciones con acceso parcial. Perplexity reporta que los mecanismos identificados dejaron de funcionar en la reevaluación posterior. Esos resultados describen pruebas concretas; no demuestran invulnerabilidad. Fuente: informe técnico de seguridad.
Para un equipo de seguridad, separar esas fronteras cambia la evaluación. Un agente puede permanecer dentro de su máquina virtual y aun así comunicarse con un destino que no debería alcanzar. Por eso propondría verificar por separado archivos accesibles, conexiones permitidas, alcance de las credenciales y capacidad de detener la ejecución. Un resultado favorable en una dimensión no debe ocultar una debilidad en otra.
Antes de adoptar una plataforma de este tipo, pediría un inventario de los activos expuestos y pruebas reproducibles de los límites definidos. También documentaría quién aplica actualizaciones y cómo se revocan las sesiones. El código abierto facilita la revisión, pero la organización debe mantener su propia configuración y comprobar que los controles siguen funcionando después de cada cambio relevante.
3. Harness²: mejorar el entorno de ejecución sin reentrenar el modelo
Harness² propone mejorar el conjunto de instrucciones, herramientas y procedimientos que guía a un agente, manteniendo fijos los pesos del modelo. Combina una adaptación para la tarea actual con la extracción de experiencia que ayuda a mejorar adaptaciones futuras. Su mecanismo compara propuestas sin requerir un verificador con respuestas correctas conocidas. Los autores reportan mejoras en tres benchmarks profesionales, con un máximo de 11,8 puntos porcentuales en LAB. Ese máximo pertenece a un escenario experimental específico. Fuente: artículo de investigación y repositorio de Google Research.
La implicación práctica es que parte de la mejora puede estar en cómo organizamos el trabajo. Una herramienta mal descrita, un documento irrelevante o una secuencia de pasos ambigua pueden limitar el resultado. Antes de cambiar de modelo, tiene sentido revisar el contexto disponible, la definición de finalización y la forma de utilizar las herramientas.
Para explorar esta idea en una empresa, prepararía un conjunto de tareas representativas y conservaría una versión estable del flujo. Cada propuesta de mejora se compararía con esa referencia utilizando casos que no hayan servido para ajustarla. Además de la calidad, mediría costo, latencia y errores nuevos. Una mejora que funciona en un tipo de informe podría empeorar otro.
La gobernanza debe alcanzar también las instrucciones que evolucionan. Los cambios deberían tener versión, autoría, evaluación y posibilidad de reversión. Si un agente puede proponer modificaciones a su propio procedimiento, conviene precisar cuáles puede activar y cuáles requieren revisión. La adaptación resulta más útil cuando podemos reconstruir por qué cambió el comportamiento.
4. Aprendizaje visual: generar una imagen y responder sobre ella
El estudio Can Visual Generation Expand What Unified Multimodal Models Know? introduce Knowledge Transfer Probing, un protocolo que incorpora conocimiento mediante entrenamiento de generación de imágenes y después comprueba su acceso con preguntas exclusivamente textuales. En siete categorías y tres modelos multimodales unificados, los investigadores observaron transferencia directa, pero desigual. Las técnicas de alineación estudiadas mejoran ese acceso, aunque persisten diferencias entre lo que el modelo reproduce visualmente y lo que responde con palabras. Fuente: estudio publicado en arXiv.
Mi interpretación es que conviene evaluar cada capacidad de forma explícita. Un sistema que genera correctamente una representación visual puede fallar al explicar sus características, y una explicación convincente necesita su propia comprobación. El resultado del estudio tampoco significa que pedirle a cualquier chatbot que dibuje algo lo reentrene o le haga aprender de forma permanente durante la conversación.
En formación técnica, plantearía un ejercicio con diagramas y preguntas sobre sus relaciones. Los estudiantes tendrían que contrastar la imagen, la respuesta y una referencia validada. El objetivo sería aprender a identificar inconsistencias entre modalidades y a justificar cuál de las representaciones merece confianza.
En una organización, esta línea de investigación puede orientar futuros ensayos con documentación visual. Antes de utilizarla en un proceso operativo, definiría qué conocimiento debe recuperarse, cómo se medirá y qué consecuencias tendría una respuesta incorrecta. La fluidez entre imágenes y texto es una posibilidad interesante; su utilidad depende de una evaluación ajustada al trabajo real.
5. Programación con agentes: acercar la evidencia al momento del cambio
Rob Zuber, CTO de CircleCI, plantea que la validación debe llegar mientras el agente todavía conserva el contexto de su modificación. La propuesta de Chunk sidecars utiliza entornos ligeros y comprobaciones acotadas, activadas mediante hooks, para devolver resultados durante el ciclo de desarrollo. CircleCI sitúa estas verificaciones junto al trabajo del agente y conserva la integración continua para comprobaciones más amplias del sistema. Fuente: explicación de CircleCI.
Este enfoque ayuda a formular una regla útil: una tarea de programación necesita una definición comprobable de finalización. El agente debe poder mostrar qué cambió, qué ejecutó y qué evidencia obtuvo. Una respuesta que afirma que el problema está resuelto todavía necesita relacionarse con el comportamiento solicitado.
Para un cambio en una API, por ejemplo, comprobaría el caso esperado, las entradas inválidas y los permisos relevantes. Para una corrección visual pequeña, bastaría una verificación proporcionada al alcance. Las pruebas deben cubrir riesgos concretos y evitar convertirse en una colección que solo repite la implementación.
También limitaría los ciclos de reparación. Un agente que modifica código y pruebas indefinidamente puede terminar rebajando los criterios de aceptación para obtener una señal favorable. El flujo debería conservar el requisito original, mostrar los fallos y escalar cuando la siguiente reparación cambie el alcance. La supervisión humana aporta especial valor al decidir si el resultado resuelve el problema correcto y si el riesgo residual es aceptable.
6. Azure MCP Server 3.0: conectar herramientas también distribuye autoridad
Microsoft anunció Azure MCP Server 3.0 como versión estable, publicada el 12 de octubre. Incorpora herramientas para Backup, resiliencia, investigaciones de SRE, Monitor y Cosmos DB, entre otras áreas, y mejora los contratos de entrada y los mensajes de error. La estabilidad del servidor no cambia la disponibilidad de cada servicio subyacente: el anuncio aclara, por ejemplo, el uso de un proveedor de recursos de vista previa para SRE Agent. Fuente: Azure SDK Blog.
El mismo anuncio especifica que algunos valores de seguridad se aplican a recursos nuevos y no reconfiguran automáticamente los existentes. También pide revisar los permisos de bases de datos durante la actualización. Es una distinción relevante: instalar una versión nueva del conector no equivale a revisar la seguridad del entorno completo.
Mi punto de partida sería una identidad de alcance limitado y un flujo de inspección: recopilar información de respaldos, identificar recursos sin la protección prevista y preparar hallazgos para revisión. Cada hallazgo debería enlazar con el recurso y con la evidencia que lo sustenta. Ese ejercicio permite comprobar utilidad sin conceder desde el inicio todas las operaciones disponibles.
La siguiente etapa podría habilitar cambios concretos, con revisión proporcional a su impacto. Restaurar un servicio, modificar protección o ejecutar una conmutación por error exige conocer dependencias y criterios de recuperación. El catálogo de herramientas puede crecer; la autoridad del agente debe seguir respondiendo a un caso de uso aprobado y a una persona responsable.
7. HydraFusion: varios modelos necesitan una evaluación común
GitHub actualizó HydraFusion e introdujo HydraFusion Max. Ambos siguen en vista previa de investigación y combinan modelos para producir una respuesta. La actualización ajusta el esfuerzo de razonamiento por etapa, incorpora críticos en paralelo y permite que la revisión inspeccione el entorno de trabajo mediante herramientas. Max dedica mayor esfuerzo a tareas exigentes. La disponibilidad en VS Code, la aplicación de Copilot y su CLI depende del plan, las funciones experimentales habilitadas y las políticas de la organización. Fuente: anuncio de GitHub.
Mi lectura es que la colaboración entre modelos merece evaluarse como un sistema completo. Contar con más revisores puede ayudar a descubrir defectos, pero también puede añadir costo y tiempo. Si todos reciben información incompleta o parten del mismo supuesto incorrecto, su acuerdo merece una comprobación adicional.
En un piloto compararía un flujo sencillo con otro de varios modelos usando las mismas tareas y criterios. Mediría defectos detectados, cambios aceptados, tiempo hasta la entrega y costo total. Una configuración más compleja debería justificar su uso con una mejora observable.
También asignaría preguntas distintas a cada revisión: corrección funcional, seguridad, compatibilidad y claridad del cambio. Las observaciones deberían apoyarse en archivos, ejecuciones o requisitos identificables. Así, la persona responsable puede resolver discrepancias con evidencia. La orquestación aporta valor cuando organiza mejor la comprobación, y ese valor debe demostrarse para cada tipo de trabajo.
8. MuseBot: el canal de conversación se convierte en una interfaz operativa
MuseBot es un proyecto abierto que conecta modelos con plataformas como Telegram, Discord, Slack y WeChat. Su repositorio documenta integraciones con proveedores como OpenAI, Gemini, DeepSeek y OpenRouter, además de funciones de recuperación de información, herramientas MCP y tareas programadas. Ofrece ejecución local y mediante Docker; las capacidades disponibles dependen del canal, el proveedor y la configuración. Fuente: repositorio de MuseBot.
La oportunidad es acercar la asistencia al lugar donde ya ocurre el trabajo. Un equipo podría consultar procedimientos, preparar borradores o recibir información operativa desde su canal habitual. Antes de conectar acciones, definiría quién puede invocarlas y qué información puede recibir cada participante.
Un ejemplo de prueba sería un bot de soporte interno que consulte una base de conocimiento aprobada y responda con referencias. Empezaría con un grupo acotado, contenido de baja sensibilidad y una ruta clara para derivar dudas. Después evaluaría si conviene permitir la creación de solicitudes, distinguiendo esa acción de la simple consulta.
Las conversaciones grupales añaden decisiones propias: quién verá la respuesta, qué sucede con un archivo compartido y cómo se evita trasladar información entre grupos con permisos distintos. Las tareas programadas necesitan además una persona responsable y un mecanismo para detenerlas. Poder desplegar un proyecto abierto reduce barreras de experimentación; convertirlo en un servicio empresarial exige operar sus identidades, datos y mantenimiento.
9. Espionaje e ingeniería social: proteger el contexto humano
The Wall Street Journal describió el 15 de octubre medidas de concienciación frente al espionaje en empresas de IA. Entre los escenarios de formación de OpenAI aparece una persona que entabla conversación con un empleado en un parque y pregunta por su trabajo. Conviene conservar la distinción: el ejemplo publicado ilustra un escenario de entrenamiento; por sí solo no acredita un incidente concreto en ese parque. Fuente: reportaje de The Wall Street Journal.
La aplicación a una empresa es más amplia que la protección de modelos avanzados. Las conversaciones sobre clientes, calendarios de lanzamiento, arquitectura o proyectos internos también pueden revelar información valiosa. Una política útil debería ayudar a las personas a reconocer qué pueden compartir y a responder con naturalidad cuando una pregunta cruza ese límite.
En formación, trabajaría con situaciones concretas: una conversación en un evento, una solicitud de documentación o un supuesto colaborador que pide acceso urgente. El ejercicio debería evaluar la comprobación de identidad, la clasificación de la información y el uso de canales internos de consulta.
La respuesta debe centrarse en conductas y evidencias, con respeto por la privacidad. También necesita un canal donde reportar dudas sin temor a una sanción automática. Una persona que pide ayuda a tiempo puede evitar una exposición mayor. Esa confianza interna es parte de la capacidad de respuesta, junto con los controles de acceso y la protección de los documentos.
10. Empleo y formación: analizar las tareas que están cambiando
En el video de IBM Technology Every Generation Thinks This Time Is Different: The AI Job Myth, Jeff Crume y Bri Kopecki utilizan ejemplos históricos para discutir cómo la tecnología transforma el trabajo. La conversación incluye la paradoja de Jevons: una mayor eficiencia puede aumentar la demanda del recurso o servicio. Es una perspectiva para pensar el cambio, no una garantía de que cada ocupación o cada trabajador obtendrá el mismo resultado. Fuente: video de IBM Technology.
Para diseñar formación, comenzaría por descomponer un rol en tareas. Algunas pueden acelerarse, otras requieren mayor supervisión y otras cambian porque ahora resulta viable ofrecer un servicio adicional. Ese mapa permite explicar qué habilidades deben desarrollarse y qué responsabilidades permanecen en las personas.
En una mesa de servicio, por ejemplo, el personal podría dedicar menos tiempo a preparar un primer borrador y más a comprender excepciones, verificar soluciones y acompañar al usuario. Eso exige practicar la revisión de respuestas, el manejo de información sensible y la escalación de incidentes, además del uso básico de la herramienta.
La adopción debería medirse también desde la experiencia del equipo: calidad del trabajo, carga de revisión, autonomía profesional y oportunidades de aprendizaje. Un programa que solo contabiliza cuentas activas o prompts enviados deja fuera lo que más importa. La formación tiene que ayudar a las personas a tomar mejores decisiones dentro del proceso que está cambiando.
11. Sistemas de diseño: convertir los criterios en contexto utilizable
En el episodio 21 de Mostly Working, Cassie Groos, de Unily, conversa con Tom Harman y Jonny Burch sobre sistemas de diseño que los agentes ayudan a construir y también consultan. Describe documentos semiestructurados por componente con propiedades, comportamiento, requisitos y accesibilidad, junto con una arquitectura de tokens para múltiples marcas. La conversación conserva un papel central para el criterio visual y la selección humana de las propuestas. Fuente: episodio y notas de Mostly Working.
La idea puede aplicarse a otros ámbitos de la organización: los criterios que viven únicamente en la experiencia de una persona son difíciles de transmitir a un agente. Documentarlos obliga a aclarar qué se espera, qué excepciones existen y cómo se reconoce un resultado correcto.
En un sistema de diseño, propondría comenzar por los componentes más utilizados. Cada uno tendría ejemplos de uso, estados de error, comportamiento con teclado y decisiones de contenido. En una PMO, el equivalente podría ser una ficha para cada tipo de informe, con fuentes admitidas, campos obligatorios y criterios de revisión.
La documentación también necesita mantenimiento. Cuando cambia un componente o una regla, el contexto que consulta el agente debe actualizarse de forma coordinada. De lo contrario, la automatización puede multiplicar una convención obsoleta. La calidad del conocimiento operativo pasa a formar parte de la calidad del producto.
12. Dos espacios para aprender con problemas concretos
Twilio Assemble London, anunciado para el 3 de noviembre, reúne a desarrolladores y líderes técnicos alrededor de IA y comunicaciones. La página del organizador presenta ejemplos prácticos y un reto de construcción, TwilioWorld: Escape the IVR, en CodeNode. Para quienes trabajan en atención al cliente, la pregunta útil es cómo mantener contexto, identificar al usuario y transferir una conversación a una persona cuando haga falta. Información y registro de Twilio.
NODES 2026 se celebrará el 12 de noviembre como un evento virtual gratuito de 24 horas. Neo4j lo orienta a aplicaciones, flujos multiagente y sistemas con contexto, con contenidos sobre grafos y desarrollo de IA. Programa y registro de Neo4j.
Mi propuesta para aprovechar estas actividades es llevar una pregunta de trabajo y volver con un experimento pequeño. En comunicaciones podría ser la transferencia de una consulta sin perder información. En grafos, la representación de relaciones entre activos, responsables e incidentes. Un objetivo definido ayuda a convertir una sesión técnica en aprendizaje aplicable y a identificar qué todavía necesita validación.
Una agenda práctica para llevar los agentes a operaciones
Las novedades se conectan cuando las llevamos a una decisión concreta de implementación. Propongo comenzar con un proceso acotado, un responsable y una referencia de cómo funciona hoy. A partir de ahí, estas cinco preguntas permiten ordenar el trabajo:
- ¿Qué resultado aceptaremos? Definir la entrega y los criterios de calidad antes de elegir el modelo.
- ¿Cuánto puede costar? Asignar presupuesto a la tarea, incluir revisión y reintentos, y decidir cuándo detenerse.
- ¿Qué autoridad necesita? Identificar datos, herramientas y acciones permitidas, con controles fuera de las instrucciones del agente.
- ¿Qué evidencia quedará? Conservar versiones, fuentes, cambios y comprobaciones suficientes para reconstruir el resultado.
- ¿Quién puede intervenir? Preparar al equipo para revisar, corregir, escalar y recuperar el proceso cuando algo falle.
Para mí, avanzar hacia una operación madura significa poder responder esas preguntas con claridad. Las herramientas seguirán cambiando; la capacidad de definir objetivos, administrar riesgos y comprobar resultados permite aprovecharlas con continuidad. Ese es el trabajo que conecta la innovación en IA con el valor que una organización puede sostener.