Conectar una capacidad de IA a una herramienta no equivale a diseñar una integración segura. El trabajo importante ocurre antes de ejecutar: definir el objetivo, decidir qué información puede consultar, limitar las acciones y establecer cómo se validará el resultado. El mínimo privilegio convierte esas decisiones en un límite claro del producto. En vez de conceder acceso amplio y confiar en que una instrucción contenga el comportamiento, la integración expone solo lo que necesita una función definida.
Define una sola función antes de conceder acceso
Empieza con una frase que describa el trabajo de la capacidad y el resultado esperado. Organizar información autorizada, preparar una propuesta y ejecutar una acción concreta exigen permisos distintos. Si la función no se puede describir con precisión, tampoco se puede limitar su acceso. Etiquetas amplias como asistente o agente ocultan la diferencia entre leer, interpretar, proponer y modificar.
El límite de diseño público de Viotus para Calculator y Valuator concreta esa estructura. Los cálculos, las reglas y los datos estructurados permanecen en sistemas controlados; una capa inteligente puede organizar información, explicar un escenario o sugerir cómo explorar una pregunta, pero debe distinguir el resultado calculado, el contenido generado y el criterio profesional. Es una decisión de permisos específica: la IA puede ayudar a navegar o interpretar el resultado, pero no hereda la autoridad del motor financiero ni presenta una generación como cálculo. La evidencia asociada debe mostrar de dónde proceden los datos, qué operación se realizó y qué parte aún requiere interpretación humana.
Separa el acceso a datos del derecho a actuar
Leer y actuar son poderes diferentes. Una integración puede consultar unos registros sin editarlos, preparar un cambio sin aplicarlo o invocar una operación sin explorar todo el servicio. Trata cada permiso como una capacidad específica, no como acceso general a una cuenta, base de datos o aplicación.
Enumera las entradas mínimas y excluye el resto. El contenido sensible debe eliminarse, reducirse o protegerse antes de llegar a la capacidad. Después, define las operaciones exactas, sus destinos y parámetros permitidos. Las acciones innecesarias amplían las consecuencias de una ambigüedad, una manipulación o un error sin mejorar el resultado.
Haz que el límite se aplique fuera de la instrucción
Las instrucciones explican la función, pero el sistema debe imponerla. Una tarea de lectura necesita credenciales de solo lectura o un adaptador incapaz de escribir. Una herramienta para un registro debe rechazar otros destinos. Un flujo de propuesta debe detenerse antes de aplicar cambios. El modelo no puede ser el único componente que decide si su propia petición está autorizada.
Utiliza entradas y salidas estructuradas cuando la tarea lo permita. Campos obligatorios, valores acotados y contratos estrechos reducen la incertidumbre. Así, la validación puede comparar el resultado con el objetivo y los permisos. El lenguaje libre puede explicar un resultado, pero no debe ampliar silenciosamente las operaciones disponibles.
Prueba solicitudes normales, ambiguas y hostiles
Prueba el caso normal, la falta de información, instrucciones contradictorias y una petición que requiera una acción no disponible. Añade intentos de obtener datos ajenos, cambiar de función, omitir la revisión o emplear una herramienta permitida sobre un destino prohibido. La respuesta segura puede ser rechazar dentro del límite o pedir una aclaración.
Comprueba el recorrido completo, no solo el texto final. ¿Recibió datos innecesarios? ¿Podía invocar otra operación aunque no lo hiciera? ¿Rechazó el adaptador un destino inválido? ¿Se detuvo el flujo antes de la revisión? Una negativa educada no demuestra mínimo privilegio si la conexión conserva autoridad amplia.
Valida y registra cada resultado relevante
El resultado debe quedar unido al objetivo, las entradas autorizadas y las operaciones que lo produjeron. Conserva información suficiente para distinguir hechos recuperados, operaciones deterministas e interpretación generada, sin convertir los registros en colecciones innecesarias de datos personales o sensibles.
La validación debe corresponder al impacto. Una sugerencia de bajo riesgo puede requerir fuentes claras y aceptación humana; un cambio propuesto, controles deterministas y una aprobación separada. El mínimo privilegio limita lo posible, la validación decide si el resultado es aceptable y el registro explica qué ocurrió.
Revisa los permisos cuando cambie la función
Los permisos deben seguir la tarea actual, no acumularse con cada novedad. Si se añade una herramienta, cambia el proveedor o aparece otra clase de información, revisa objetivo, entradas, operaciones, validación y ruta de fallo. Elimina el acceso que ya no sea necesario. Un modelo más capaz no justifica por sí solo un límite mayor.
Pregunta si la función sigue siendo única y clara, si cada dato y operación son necesarios, si el sistema puede imponer el límite sin confiar en texto generado y si un revisor puede reconstruir el resultado con un registro proporcionado. Ante la duda, mantén cerrada la capacidad hasta reducir su alcance.