Qué funciones abrir a los agentes de IA

Habilite funciones de su empresa para asistentes de IA cuando una tarea concreta del cliente lo justifique y sus sistemas puedan imponer los límites. Empiece por la tarea, los datos necesarios y la persona responsable del resultado. Una sección pública de preguntas frecuentes quizá necesite una página más clara. El estado privado de un pedido requiere acceso controlado. Una reserva necesita un proceso definido de aprobación y confirmación.

Que una función sea «invocable por un agente» significa que un asistente puede ejecutar una función que usted ofrece, como consultar disponibilidad. No significa darle acceso general a sus sistemas.

Elija la primera tarea y sus límites

Imagine una empresa de servicios cuyos clientes preguntan a menudo si su trabajo está listo. Una primera herramienta útil podría devolver el estado de un expediente. Sus reglas deberían indicar:

• Quien llama debe tener permiso para ver ese expediente; conocer su referencia no basta.
• La respuesta contiene el estado autorizado para el cliente, su última actualización y una vía de soporte. Excluye notas internas y registros de otros clientes.
• La herramienta no puede editar el expediente, emitir un reembolso ni prometer una fecha de finalización ausente del sistema de origen.
• Si la fuente no está disponible o falla el acceso, informa de esa situación sin inventar un estado.

Compare esta opción con el portal de clientes existente antes de crear otra interfaz. Si el portal ya resuelve el problema, confirme por qué los clientes necesitan una conexión con asistentes y cómo la mantendrá.

En una primera versión, deje fuera del alcance los pagos, reembolsos, cambios destructivos y exportaciones masivas de datos personales. Cualquier ampliación debe tener su propia aprobación y pruebas. Pedir al modelo que se comporte bien no es un control de acceso.

La lectura también necesita protección

Una consulta puede divulgar un documento privado, revelar el pedido de otro cliente o presentar un precio antiguo como vigente. Estos resultados pueden perjudicar al cliente aunque no cambie ningún registro.

Determine el acceso a partir de una identidad verificada y permisos aplicados en el servidor. Un account_id enviado por el asistente no demuestra que le pertenezca la cuenta. Incluso dentro de una organización, un empleado puede no tener derecho a todos los documentos.

Qué aporta MCP y qué debe implementar

Model Context Protocol (MCP) es una forma de ofrecer herramientas a los asistentes. Las referencias siguientes corresponden a su revisión del 28 de julio de 2026, consultada el 9 de octubre de 2026. Confirme qué versiones admiten realmente su cliente y servidor.

La especificación de autorización cubre autorización HTTP, validación de tokens y alcances de permisos. No se limita a transportar un inicio de sesión. Su implementación aún debe relacionar los permisos concedidos con las operaciones y registros permitidos. No debe aceptar un token válido destinado a otro servicio.

La especificación de herramientas exige validar entradas, aplicar controles de acceso y límites de llamadas, y sanear salidas en el servidor. Recomienda supervisión humana y solicitudes de confirmación, pero no impone un único diseño de interacción. Conectar un cliente MCP no demuestra que esos controles funcionen en su aplicación.

La guía de seguridad también advierte que poseer un identificador de estado no constituye autenticación. Una referencia de flujo o carrito identifica algo que comprobar; no demuestra quién puede usarlo.

Haga que la aprobación sea específica y exigible

Ante una reserva propuesta, muestre servicio, zona horaria, fecha, precio y condiciones de cancelación antes de la confirmación. Registre lo aprobado. Si cambia un detalle importante, obtenga otra aprobación. Un indicador «aprobado» generado por el modelo no demuestra que el cliente haya aceptado.

Separe preparar la propuesta de confirmarla. Si guardar un borrador crea un registro o envía una notificación, ya es una escritura que debe contemplarse en los permisos. El servidor debe rechazar el compromiso si falta la aprobación requerida para esas condiciones exactas.

Nuestra oferta de sistemas accesibles para agentes empieza con herramientas de lectura y añade al final las acciones que crean obligaciones, con confirmación del cliente para lo irreversible. Nuestro piloto tiene sus propios requisitos de aprobación humana para escrituras, mensajes a clientes y movimientos de dinero. Un ejemplo general de arquitectura no amplía el alcance contratado.

Pruebe rechazos y recuperación antes del lanzamiento

Use cuentas y registros de prueba. Guarde el resultado esperado junto al observado para que otro desarrollador pueda repetir la prueba.

Use permisos acotados, vencimiento de credenciales y revocación probada. Separe credenciales cuando lo exija el límite de seguridad; una cuenta distinta por herramienta no es una regla universal. Defina tiempos máximos de espera, límites de reintentos y cuotas por cliente que llama. Para escrituras, use un identificador estable de operación y prevención de duplicados en el servidor, sin depender de que el modelo recuerde el intento anterior.

Registre quién llama, operación, decisión de permisos, referencia de aprobación pertinente y resultado. Oculte secretos y datos personales innecesarios; defina acceso a los registros y plazo de conservación. Asigne a un operador que pueda retirar una herramienta y aclarar un resultado incierto. La guía de pilotos para compras explica cómo documentar esas responsabilidades.

Qué demuestra nuestro ejemplo público

El 9 de octubre de 2026 consultamos tools/list en mcp.strataigize.com, sus metadatos públicos de autorización y auth.md. La lista anunciaba siete herramientas públicas de lectura y una herramienta autenticada, request_growth_audit, para solicitar una consulta de crecimiento gratuita. Aunque conserva ese nombre antiguo, solicita una consulta, no la AI Opportunity Audit de pago.

Esa solicitud es una escritura. La documentación exige que una persona concreta la haya pedido e indica que alguien revisa los envíos; no se reserva nada automáticamente. También distingue expresamente el registro abierto de un cliente de software de la comprobación de identidad de una persona.

Esta revisión confirma la interfaz y las reglas publicadas. No enviamos una solicitud ni probamos su seguridad en esta revisión. La lista de herramientas no demuestra uso externo ni ventas.

Antes de contratar una interfaz, documente la primera tarea del cliente, datos permitidos, acciones prohibidas, punto de aprobación, pruebas de fallo, operador y procedimiento de retirada. Mida tareas terminadas correctamente junto con rechazos, excepciones y tiempo de revisión. El número bruto de llamadas incluye reintentos y fallos, por lo que no es un recuento de éxitos. La consultoría de IA puede ayudar a definir el alcance antes de contratar la integración.