Privacidad y alcance

Una respuesta, una empresa

Al autorizar elegís qué empresas puede consultar la conexión. Si administrás una sola, es esa. Si administrás varias, marcás las que quieras y después te movés entre ellas en la misma conversación, sin volver a entrar.

Ese conjunto queda fijado en la credencial y no se puede ampliar desde el asistente: pedir una empresa que no marcaste se rechaza, tanto si existe como si no. Cada llamada responde sobre una sola de ellas; el servidor nunca mezcla dos empresas en una misma respuesta.

Si la conexión cubre varias y la pregunta no deja claro cuál, el servidor no elige por vos: responde con la lista para que el asistente te pregunte. Una respuesta sobre la empresa equivocada se lee perfecta y no avisa de nada, y eso es peor que no responder. get_context es la manera de confirmar, antes de responder nada, qué empresas alcanza esta conexión.

La membresía se revalida en cada llamada contra las empresas que esa persona sigue teniendo asignadas como staff — no solo al autorizar. Sacarle a alguien su rol de staff en una empresa le corta el acceso MCP a esa empresa en el mismo instante, sin que haga falta revocar nada aparte. Perder una de cinco deja las otras cuatro funcionando; perder todas cierra la conexión.

Solo lectura, salvo un pedido de reporte

De las 22 herramientas, 21 son lecturas. La única excepción es request_report, que encola un trabajo para generar un Excel o CSV. Ninguna herramienta borra ni modifica datos de la empresa.

Los datos personales están detrás de dos llaves independientes

Nombres, correos, teléfonos y números de documento no aparecen por default. Para que aparezcan tienen que estar abiertas las dos llaves a la vez:

1. La del deployment — la variable MCP_EXPOSE_PII en el hackÜ que responde. Sale apagada. Prenderla manda datos personales de colaboradores de clientes corporativos al modelo que esté usando el staff, así que exige que ese proveedor sea un subprocesador declarado con DPA firmado antes de activarla.
2. La del scope de la credencial — users:pii, otorgado por persona.

Ambas existen para que una credencial pueda servir para preguntas agregadas o dashboards sin exponer jamás el teléfono de alguien, y para que revocar ese alcance no implique revocar la integración entera.

Toda respuesta que puede incluir estos campos trae pii_included: true|false explícito. Cuando es false, las personas vienen identificadas por user_id únicamente.

La segmentación recorta antes de responder

Si el staff que autorizó la credencial está restringido a un segmento de la empresa (segment_restriction), las herramientas de personas devuelven solo esa porción — no la empresa entera. get_context expone ese límite explícitamente, y varias respuestas (list_users, get_company_overview) incluyen una nota aclarando que los conteos son del segmento, no de la compañía completa. Presentar esa cifra como si fuera el total de la empresa es un error de lectura, no un límite de los datos.

Los reportes van al correo de la persona, nunca a la conversación

request_report no devuelve el contenido del archivo. Encola un trabajo, manda el enlace de descarga al correo del staff que lo pidió, y ese enlace exige su propio login de hackÜ para abrirse — el modelo no puede leerlo ni aunque quisiera. Es deliberado: los datos personales de un reporte pasan por el correo y el login de la persona, nunca por el chat.

Consejo

Si una respuesta pide report_type fuera de la lista válida (users, users_csv, evaluations, evaluations_detail, surveys, ssaa, point_logs, pensum_users, finished_courses), o si ya hay uno idéntico en curso, hackÜ lo rechaza — ver Problemas comunes.