Software Insights

Glass Box de Make: el concepto para gobernar IA y automatizaciones

Escrito por Equipo de redacción de Drew Tech | Nov 4, 2026, 8:00:01 PM

Por qué la IA en los procesos exige otro nivel de supervisión

Cuando un agente de IA trabaja sobre varias herramientas, el riesgo deja de ser solo una respuesta incorrecta. Puede actualizar un CRM, escribir a un cliente o modificar un pedido con los accesos de alguien de tu empresa. La pregunta se vuelve operativa: qué hizo, con qué permisos y cómo intervenir si algo falla.

El desafío no se limita a los agentes. Una misma operación puede combinar flujos fijos, pasos de IA y decisiones autónomas. Si cada pieza se revisa por separado, nadie tiene la imagen completa.

Make puso este problema en el centro de Waves ‘26, cuyos anuncios publicó el 20 de octubre de 2026. Según la compañía, casi todas las empresas con las que conversa ya implementaron IA, pero pocas pueden explicar qué está haciendo. El riesgo crece con el alcance: la plataforma ofrece más de 3.500 integraciones, y cada conexión amplía lo que hay que supervisar.

<<<Make Waves ‘26: novedades sobre IA empresarial, gobernanza y seguridad>>>

 

Qué es Glass Box y qué no es

La propuesta de Make es que una empresa debe funcionar como una caja de cristal, no como una caja negra. Eso implica tres condiciones para cada solución, proceso y acción:

  • Visible: puedes ver qué existe y qué ocurrió.
  • Con permisos: está definido qué puede hacer cada persona o agente.
  • Reversible: existe una forma de intervenir y deshacer o corregir.

Glass Box es una visión de plataforma, no una funcionalidad específica. No hay un módulo con ese nombre. La visión se apoya en capacidades organizadas en cuatro pilares: Discover, Build, Govern y Observe.

Tampoco conviene confundirla con MakeOS. Make presenta MakeOS como un producto nuevo que lleva este enfoque a la operación con agentes, pero está en beta cerrada y con lista de espera. Parte del principio ya puede aplicarse con las capacidades actuales de la plataforma.

Tres niveles de decisión para la IA

Glass Box no significa dar más autonomía a la IA, sino decidir cuánta conviene en cada tarea y poder observarla. Make distingue tres niveles:

  • Agentes de IA (autónomo): deciden, se adaptan y ejecutan por su cuenta.
  • Flujos con IA (guiado): tu proceso incorpora criterio de IA en momentos definidos.
  • Flujos automatizados (totalmente controlado): los pasos se ejecutan exactamente como los definiste.

La regla práctica es simple: si la tarea solo requiere ejecutarse, usa automatización; si requiere interpretar o razonar, considera un agente.

<<<Agentes de IA en acción: transforma el trabajo en resultados con Make>>>

 

Cuatro preguntas que debes poder responder

¿Qué se ejecutó?

Esta pregunta tiene dos niveles: el panorama general y cada ejecución.

  • Make Grid genera un mapa casi en tiempo real de escenarios, aplicaciones, almacenes de datos y componentes de IA. También señala errores y dependencias.
  • El historial de ejecuciones registra lo que ocurrió en cada corrida y ayuda a localizar dónde falló.
  • La pestaña Reasoning muestra paso a paso cómo procesó un agente la solicitud, incluidas las herramientas que usó y las decisiones que tomó.

Make indica además que Grid ya puede incluir agentes y automatizaciones de otras plataformas, con búsqueda de texto completo en objetos, prompts y registros.

¿Quién autorizó el acceso?

En el modelo de gobernanza de Make, un agente no es un actor independiente. Actúa en nombre de alguien, con su rol y sus conexiones. Cuando llama a Make por MCP, se comprueba el rol de su propietario en el momento de actuar.

Esto tiene una consecuencia directa: si una persona tiene permisos excesivos, su agente también puede tenerlos. Revisar los accesos humanos es, por lo tanto, parte de la seguridad de los agentes.

Las capacidades disponibles para acotar ese riesgo son:

  • Roles de equipo y organización: definen qué puede ver o modificar cada usuario.
  • Custom Roles: permiten elegir permisos uno por uno. Son exclusivos del plan Enterprise.
  • Private Spaces: mantienen experimentos y credenciales separados del resto de la organización.

¿Qué información se utilizó?

La respuesta requiere reconstruir tanto el contexto como los datos de la ejecución. En una corrida de agente, puedes revisar:

  • Las instrucciones y la entrada que recibió.
  • Las herramientas llamadas y sus resultados, dentro del razonamiento registrado.
  • La base de conocimiento, si el agente usa contexto de la empresa mediante Knowledge.
  • Los registros de ejecución, que guardan los datos procesados en cada corrida.

Aquí hay una decisión de diseño. Make permite activar un ajuste para no conservar esos datos en los registros. Puede ser adecuado para información sensible, pero reduce lo que podrás investigar después. Conviene definirlo por proceso, junto con las áreas de seguridad y privacidad.

¿Cómo investigar y corregir un problema?

Un flujo de respuesta razonable tiene cuatro pasos:

  1. Detectar. Usa event subscriptions para recibir avisos, incluso de corridas de agentes que terminan pero salen mal, y revisa los indicadores de error en Grid.
  2. Reconstruir. Consulta el historial y Reasoning para ver qué pasó y por qué.
  3. Identificar cambios. Los registros de auditoría muestran qué se modificó, quién lo hizo y cuándo. Make indica que ya cubren cambios de personas, agentes y clientes MCP. Están disponibles en Enterprise y se guardan 12 meses.
  4. Corregir. Las ejecuciones incompletas conservan una corrida fallida para reintentarla o resolverla manualmente. Debes activarlas en cada escenario, porque vienen desactivadas de forma predeterminada.

La reversibilidad merece especial cuidado. Reintentar una corrida no deshace por sí solo un correo enviado o un reembolso emitido en otro sistema. Para esas acciones, define de antemano quién corrige y cómo. Trata este punto como un requisito de diseño, no como una garantía automática.

 

 

Caso hipotético: un agente que procesa un reembolso

Este ejemplo es ilustrativo. Una empresa de comercio electrónico diseña en Make un proceso con los tres niveles de decisión:

  1. Automatización: al entrar un ticket en Zendesk, un flujo consulta el pedido en Shopify.
  2. Paso de IA: un módulo clasifica el motivo del reclamo.
  3. Agente: revisa la política de reembolsos en Knowledge, decide el monto, actualiza el contacto en HubSpot, registra la solicitud en el sistema financiero y avisa por Slack.

Un día, finanzas detecta un reembolso total donde correspondía uno parcial. Así se investiga:

  • Qué se ejecutó: Grid ubica el escenario y sus dependencias, y el historial identifica la corrida.
  • Qué información se usó: Reasoning muestra que el agente se basó en una versión desactualizada de la política.
  • Quién autorizó el acceso: el agente operaba con la conexión financiera de su propietario, con más alcance del necesario.
  • Qué cambió: los registros de auditoría muestran que nadie modificó el escenario. El problema estaba en el contenido, no en el flujo.

La corrección combina varias acciones. Finanzas ajusta el reembolso en su sistema y el equipo actualiza la política en Knowledge. Además, se acotan los permisos de la conexión.

Por último, los importes altos dejan de depender del agente. Una regla fija los envía a una persona. Cuando la aprobación humana nativa esté disponible, el equipo podrá evaluarla para este paso.

La lección: la visibilidad no evitó el error, pero permitió entender la causa y reducir el riesgo de que se repita.

 

 

Preguntas antes de ampliar el uso de agentes

Si tu empresa no puede responder estas preguntas, conviene resolverlas antes de escalar:

  • Inventario: ¿sabemos qué automatizaciones y agentes existen, y qué sistemas tocan?
  • Responsables: ¿cada uno tiene un propietario identificado?
  • Permisos: ¿cada agente tiene solo el acceso que necesita, o hereda permisos demasiado amplios?
  • Autonomía: ¿qué decisiones puede tomar la IA y cuáles deben quedar en manos de una persona?
  • Datos: ¿qué información puede usar el agente y qué registros debemos conservar?
  • Trazabilidad: ¿podríamos reconstruir una ejecución problemática si auditoría lo pidiera?
  • Corrección: ¿sabemos cómo revertir o compensar cada acción con impacto externo?
  • Valor: ¿medimos costo, calidad y resultado por proceso?

 

 

Conclusión

Glass Box de Make es un marco para operar la IA con visibilidad, permisos y capacidad de intervención. No es una función que resuelva la gobernanza por sí sola. Su valor depende de cómo combines las capacidades disponibles con responsables claros y permisos bien acotados.

Distingue lo que ya existe de lo anunciado, y lo que incluye tu plan de lo que requiere Enterprise. Luego empieza por un proceso concreto: mapea sus dependencias, revisa sus accesos y prueba cómo investigarías un error. Si puedes explicar qué ocurrió y corregirlo, tendrás una base sólida para ampliar el uso de agentes.