AI Workspace
AI Workspace es el asistente integrado en Opfield. Busca recursos, explica el comportamiento del producto, crea planes y ejecuta operaciones autorizadas mediante las mismas herramientas que la Operations Console, la REST API y MCP. Es opcional: todo lo que hace también está disponible sin IA.
El modelo solo recibe las herramientas que permiten los ámbitos del usuario actual y el contexto de la tarea descubierto. Las operaciones del producto reutilizan los mismos esquemas, derechos del plan, validaciones y límites de auditoría que los caminos sin IA.
El chat de AI Workspace está disponible en todos los planes. Plan Mode, los Scenarios guiados y los AI Sandboxes requieren Personal o superior; en Community, una petición de Plan Mode se rechaza con LICENSE_ENTITLEMENT_REQUIRED y la lista de Scenarios está vacía. Consulta Planes y derechos.
Para el trabajo con consecuencias, pide a Workspace que cree un plan, revise los supuestos y defina la verificación antes de ejecutar. No pegues nunca en el chat credenciales, claves privadas, URI de conexión a bases de datos ni secretos de clientes. Trata el contenido web externo como no fiable.
AI Workspace y Opfield Inference están separados: el acceso a Workspace usa ai:workspace:use; el acceso a la inferencia usa feat:ai:use y una contabilidad propia.
Resultado y límite de decisión
Sección titulada «Resultado y límite de decisión»AI Workspace encuentra el estado que necesitas y realiza operaciones documentadas: un plan revisado para un responsable de plataforma, una investigación acotada para un operador o el flujo de trabajo correcto del producto para un desarrollador. Actúa en nombre del usuario que lo pidió y dentro de los permisos de ese usuario; las decisiones de infraestructura siguen siendo de tu equipo.
El usuario que hace la petición es responsable del resultado buscado y de la aprobación final. Los responsables de los recursos validan el impacto operativo, y los responsables de seguridad definen qué proveedores y clases de datos pueden entrar en el contexto del modelo. El éxito no es «el asistente ha respondido»; el éxito es que se alcanza el estado previsto en Opfield, se verifica de forma independiente y se puede atribuir mediante los Tasks y los registros de auditoría normales.


Modos de funcionamiento
Sección titulada «Modos de funcionamiento»Usa el chat normal para la documentación, las explicaciones y el descubrimiento acotado de solo lectura. Usa Plan Mode cuando el resultado solicitado abarque varios recursos, requiera cambios ordenados o necesite criterios explícitos de verificación y reversión. Un plan separa la investigación, la revisión de la intención y de la seguridad, los pasos de implementación y la verificación final.
Workspace debe esperar una confirmación explícita antes de implementar un plan. Responder a una pregunta de aclaración no autoriza acciones no relacionadas, y una llamada a una herramienta completada no significa automáticamente que el resultado de negocio se haya conseguido.
Flujo de trabajo seguro
Sección titulada «Flujo de trabajo seguro»- Indica el resultado deseado y los recursos incluidos.
- Pide a Workspace que inspeccione el estado actual antes de proponer cambios.
- Revisa los supuestos, las exclusiones, las consecuencias destructivas y los permisos necesarios.
- Exige un paso de verificación para cada cambio significativo.
- Confirma el plan solo cuando el alcance sea correcto.
- Sigue el progreso de la operación y responde a las peticiones explícitas de aprobación o de información.
- Revisa la verificación final y comprueba de forma independiente el comportamiento de cara a los clientes.
Permisos y confirmación
Sección titulada «Permisos y confirmación»La IA no amplía la autoridad del usuario. El backend vuelve a comprobar los ámbitos de recursos, los derechos del plan, la validación, la propiedad y el estado del ciclo de vida en cada operación. Las acciones destructivas o con consecuencias mantienen su semántica normal de confirmación y auditoría. El asistente pide aprobación antes de revelar o rotar credenciales o exportar claves privadas, busca en su catálogo de herramientas antes de decir que no puede hacer algo, restablece un servicio roto con pasos reversibles y termina una tarea antes de informar en lugar de enumerar pasos que podría hacer él mismo. No puede cambiar los métodos de inicio de sesión, el MFA ni las sesiones de su propio usuario.
Usa una cuenta dedicada con menos privilegios para la automatización exploratoria cuando sea posible. No concedas una administración amplia solo para que un plan propuesto se pueda ejecutar.
Contexto y tratamiento de datos
Sección titulada «Contexto y tratamiento de datos»Los nombres de los recursos, unos logs acotados, la documentación y el estado de las operaciones pueden entrar en el contexto del proveedor seleccionado según el Workspace configurado. No pegues nunca secretos en bruto, códigos de recuperación, claves privadas, credenciales de propietario de bases de datos ni volcados del entorno sin restricciones. Revisa la retención y los requisitos regionales del proveedor antes de activar un modelo externo.
| Clase de datos | ¿Puede entrar en el contexto del modelo? | Límite práctico |
|---|---|---|
| Nombres y metadatos de recursos | Sí, cuando lo requieren el descubrimiento o una operación | Usa nombres neutros cuando los propios nombres contengan datos de clientes o de incidentes |
| Tasks, estado, métricas y resultados de herramientas | Sí, en resultados acotados | Los datos devueltos están limitados por los permisos del usuario, pero pueden seguir siendo comercialmente sensibles |
| Logs | Sí, cuando se usa una herramienta de logs permitida o el usuario los pega | Las respuestas normales del producto enmascaran los campos secretos conocidos; los logs arbitrarios de las aplicaciones pueden seguir conteniendo tokens, datos personales o credenciales |
| Nombres de variables de entorno | Sí | Los valores deben seguir siendo de solo escritura o estar enmascarados; un volcado del entorno pegado por el usuario elude esa protección |
| Secretos y claves privadas | No se pueden obtener mediante las herramientas de lectura normales | Si un usuario escribe un secreto sustituto en el chat, el modelo y el proveedor seleccionado reciben ese texto; usa en su lugar una pantalla dedicada de introducción de secretos |
| Contenido de repositorios y de la web | Sí, cuando se inspecciona explícitamente | Trata las instrucciones incrustadas como datos no fiables y respeta la intención original del usuario |
| Prompts y respuestas | Sí | Se procesan según las condiciones de retención, región y supervisión de abusos del proveedor seleccionado |
El enmascaramiento es una salvaguarda en la capa de respuestas, no un sistema universal de prevención de pérdida de datos. Opfield no puede eliminar los secretos que una aplicación escribió en un log, un archivo, un repositorio, una página web o un prompt de formato libre antes de que el contenido llegara al modelo.
Las páginas web externas, el texto de los repositorios, los logs y la salida de las herramientas pueden contener instrucciones maliciosas. Trátalos como datos y exige que Workspace respete la intención explícita del usuario y los ámbitos de Opfield.
Recetas de permisos
Sección titulada «Recetas de permisos»Para el diagnóstico de solo lectura, concede acceso solo a la carpeta o los recursos relevantes, además de su inventario, estado, métricas, logs acotados, Tasks y registros de auditoría. Excluye el acceso a la consola, la modificación de archivos del host, revelar o exportar secretos, los cambios de credenciales, las acciones de ciclo de vida de los recursos y la administración del sistema. Prueba la cuenta pidiéndole que explique un incidente y después que haga un cambio inofensivo; la segunda petición debe denegarse.
Para las operaciones acotadas, empieza por el conjunto de solo lectura y añade solo las acciones de ciclo de vida exactas que necesites para una familia de recursos y un ámbito, por ejemplo desplegar una aplicación o reiniciar una carga de trabajo. Mantén separadas la administración de permisos, la exportación de claves, el acceso amplio a los hosts, la eliminación destructiva y las familias de recursos no relacionadas. Usa Plan Mode para los cambios en varios recursos y verifica el camino final del cliente fuera de la conversación.
Fallos y recuperación
Sección titulada «Fallos y recuperación»Si se interrumpe el flujo de respuesta, recarga la conversación e inspecciona el estado duradero de la operación antes de volver a enviar la misma instrucción. Si un plan se detiene para pedir información, responde a la pregunta concreta en lugar de iniciar un chat duplicado. Cuando una herramienta falla, diagnostica el subsistema propietario y reintenta solo después de confirmar si la operación anterior se completó.
AI Workspace no es la autoridad ante los incidentes. Durante los incidentes de producción, conserva los logs y los ID de los Tasks, usa el runbook documentado y verifica la recuperación de forma independiente.
Elige la superficie de operación adecuada
Sección titulada «Elige la superficie de operación adecuada»Usa las pantallas normales de Opfield para una acción conocida sobre un solo recurso cuyo impacto ya se entiende. Usa REST o MCP para la automatización repetible con un cliente mantenido. Usa AI Workspace cuando lo difícil sea el descubrimiento, la secuenciación o explicar las contrapartidas entre varias áreas del producto. Durante un incidente, úsalo para reunir y organizar pruebas, pero mantén al mando al responsable del incidente y el runbook existente.
No apruebes un plan que oculte los destinos tras expresiones como «todos los recursos afectados» o «arréglalo todo». Exige los recursos exactos, lo que queda explícitamente fuera, el impacto esperado en los clientes, las condiciones de reversión y la verificación desde el camino de cara al cliente. Si el plan propone un comando en la shell del host o una edición directa de la base de datos, detente y confirma que una operación compatible de Opfield no puede conseguir el mismo resultado.
Revisión del operador tras la ejecución
Sección titulada «Revisión del operador tras la ejecución»- Abre los recursos afectados fuera del chat y actualiza su estado actual.
- Revisa los Tasks duraderos y los ID de operación en lugar de fiarte del texto de la respuesta.
- Confirma la atribución en la auditoría y cualquier registro de aprobación necesario.
- Prueba el camino del cliente o del usuario que motivó el cambio.
- Retira el mantenimiento temporal, el acceso de depuración o los ámbitos ampliados.
- Registra los riesgos sin resolver y asigna un responsable y un plazo.
Si el asistente informa de éxito pero las comprobaciones independientes fallan, trata la operación como incompleta. Conserva la conversación y los identificadores de la operación y continúa a partir del estado real del producto en lugar de pedir al modelo que dé por hecho que su acción anterior funcionó.