Lista de verificación de seguridad para proveedores de soporte con IA: 25 preguntas para 2026

¿Por qué un informe SOC 2 no basta para un proveedor de soporte con IA?

Trabajo en el lado del agente de eesel, así que paso mucho tiempo en la parte del producto que más examinan los revisores de seguridad. eesel también ha perdido ventas justamente por esta lista. Una plataforma de salud de EE. UU. en Zendesk detuvo la conversación a media demo porque en ese momento no podíamos firmar un BAA. Una gran plataforma de podcasts en Freshdesk no podía avanzar sin un SOC 2 terminado. Esas dos llamadas son buena parte de la razón por la que eesel ahora tiene un centro de confianza público con un calendario de auditoría fechado, así que seré honesto sobre dónde estamos.

Esto es lo que me enseñaron esas llamadas. Un informe SOC 2 te dice que un proveedor opera sus sistemas con cuidado: cifrado, revisiones de acceso, gestión de cambios, respuesta a incidentes. Los Trust Services Criteria del AICPA cubren seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. Ese es el mínimo, y debes exigirlo.

Pero un agente de soporte con IA es otro tipo de proveedor. No solo almacena tus tickets. Los lee, los envía a un modelo de lenguaje grande operado por otra empresa y, en muchas configuraciones, puede reembolsar un pedido o cambiar una cuenta. Ninguna categoría de SOC 2 pregunta "¿puede un cliente convencer a tu bot de hacer un reembolso?"

El propio AICPA ha empezado a advertir a los compradores sobre la mentalidad de coleccionar insignias. Su página sobre SOC 2 enlaza un artículo de 2026 titulado "Promises of 'fast and easy' threaten SOC credibility." Así que lee el informe, revisa sus fechas y comprueba si el producto de IA está realmente dentro de su alcance. Luego sigue adelante.

La buena noticia es que no tienes que inventar la segunda capa. Los marcos ya existen:

Si tu equipo de seguridad ya usa SIG o CAIQ, pide al proveedor una copia completada antes de la primera llamada. Ahorra una semana. La lista de abajo es lo que yo añadiría encima, redactada para un responsable de soporte y no para un auditor.

La lista de verificación de seguridad para proveedores de soporte con IA

Marca los puntos a medida que el proveedor los responda. Los marcados como críticos son los que trataría como bloqueantes antes de que un agente de IA toque tickets reales de clientes. El contador de arriba lleva la cuenta.

El resto del artículo recorre los seis grupos, con lo que 7 proveedores de helpdesk conocidos publican realmente sobre cada uno. Elegí Zendesk, Freshworks, Salesforce, HubSpot, Gorgias, Help Scout y Front porque su IA vive dentro del helpdesk, así que sus páginas de confianza son las que la mayoría de los equipos de soporte acaban leyendo.

¿Entrenan con tus tickets?

Es la primera pregunta que todos hacen y las respuestas son menos uniformes de lo que esperarías. En realidad hay tres preguntas distintas escondidas: si el proveedor entrena sus propios modelos con tus datos, si lo hace el proveedor del modelo detrás, y si tus datos ayudan a los agentes de otros clientes.

La mayoría de los proveedores es clara sobre el proveedor del modelo. Zendesk dice que sus subencargados de LLM "cannot use your Service Data to train their models", y Front prohíbe a sus subencargados usar datos de clientes "to train foundation models". Los modelos propios de los proveedores son donde se pone interesante:

• Zendesk entrena "generic, cross-account machine learning models" para clasificación con datos de servicio, tras un paso de saneamiento que elimina identificadores, según su Trust Center. Sus funciones generativas son un caso aparte.
• Gorgias es inusualmente directo: "Our AI Agent does learn from interactions from other brands," con salvaguardas para reducir fugas, dice su FAQ de seguridad del AI Agent. Esa honestidad es útil. También significa que el agente de un competidor puede beneficiarse del historial de tus tickets, algo que algunas marcas aceptarán y otras no.
• Freshworks ofrece una exclusión del entrenamiento, pero se hace escribiendo a support@freshworks.com, según su marco de procesamiento de datos de Freddy AI. Consigue la confirmación por escrito.

Luego está la retención en el proveedor del modelo. "Cero retención de datos" significa que el proveedor no guarda nada una vez que devuelve una respuesta. Zendesk, Salesforce y Front lo afirman para sus funciones generativas. La documentación de AI Assist de Help Scout dice que OpenAI almacena datos "for up to 30 days." Treinta días no son un obstáculo para la mayoría de los equipos, pero es un número con el que tu DPA debería coincidir.

Por parte de eesel: no entrenamos ni ajustamos modelos con tus datos, y los cuatro proveedores de modelos abiertos de nuestra lista de subencargados funcionan con cero retención de datos. Para Anthropic, OpenAI y Google nos apoyamos en sus términos comerciales de API, que no permiten entrenar con datos de API. Si necesitas por escrito un número de retención para esos tres, pídenoslo como parte del paquete de seguridad en lugar de fiarte de lo que diga un artículo de blog.

¿Adónde va realmente un ticket?

Imagina un correo de un cliente. Llega a tu helpdesk, se sincroniza con el proveedor de IA, se envía a un proveedor de modelos y se almacena en un índice de búsqueda (a menudo una base de datos vectorial) y en algunos registros. Cada salto es un lugar donde puede guardarse, copiarse o cruzar una frontera.

Según el artículo 28 del GDPR, el proveedor del modelo es un subencargado, y el proveedor no puede añadir uno sin avisarte y darte la oportunidad de oponerte. Así que la lista de subencargados es un documento legal, no una formalidad. Es también donde aparece la deriva. La FAQ de Gorgias dice que AI Agent usa "OpenAI, Anthropic, and internally fine-tuned LLMs," mientras que su lista de subencargados, revisada por última vez el 30 de marzo de 2026, incluye a OpenAI como único proveedor de IA. La lista de Help Scout está fechada en enero de 2025. Ninguna es necesariamente errónea (un modelo alojado en un proveedor de nube puede figurar legalmente en la fila de ese proveedor de nube, justo como explica Salesforce su uso de Anthropic), pero es una pregunta que conviene hacer.

La residencia de datos es la otra mitad, y es donde está la letra pequeña. Cada uno de estos puntos está documentado por el propio proveedor:

• HubSpot: para los centros de datos de Australia y Canadá, cada fila de proveedor de IA en su página de subencargados muestra "United States." El centro de datos de la UE mantiene el procesamiento de IA en el Espacio Económico Europeo.
• Salesforce: si los endpoints de la región no responden, "the request falls back to Azure OpenAI in the United States." Desactivarlo requiere antes Data 360, según su documentación de enrutamiento geográfico.
• Freshworks: para cuentas de India, Australia y Oriente Medio/África, algunas funciones se procesan en EE. UU., pero "AI features that require data processing outside your primary hosting region are disabled" por defecto. Ese valor por defecto es bueno. Más sobre Freddy en la guía de residencia de datos de Freshdesk.
• Zendesk: el uso de IA "does not impact any Customer data locality commitments," salvo que productos adquiridos como AI Agents - Advanced "may remain on" Google Cloud en EE. UU. o Europa "for a period of time," según el Trust Center.
• Front: eliges alojamiento en EE. UU. o en el EEE, pero los datos "may be otherwise processed" fuera de él "as reasonably necessary," según su política de alojamiento.

Nada de esto está oculto. Todo está en las páginas de los propios proveedores, lo cual les honra. Simplemente no está en la página que te envía tu ejecutivo de ventas. En eesel, producción corre en AWS en EE. UU. (N. Virginia) por defecto, y nuestro centro de confianza vincula la residencia completa en la UE, incluido el procesamiento de IA, al plan Enterprise. Confirma el plan antes de suponer nada.

¿Qué puede hacer el agente en tu helpdesk?

Esta es la sección a la que dedicaría más tiempo, porque es donde ocurre el daño real. OWASP lo llama Excessive Agency: acciones dañinas en respuesta a "unexpected, ambiguous or manipulated outputs." Sus tres causas raíz son demasiada funcionalidad, demasiados permisos y demasiada autonomía. Traducido a soporte, es un agente que puede emitir reembolsos cuando solo necesitaba consultar pedidos.

El lado legal también se ha puesto al día. En Moffatt v. Air Canada, un tribunal de Columbia Británica rechazó el argumento de la aerolínea de que su chatbot era responsable de sus propias palabras: "It makes no difference whether the information comes from a static page or a chatbot." La indemnización fue pequeña ($812.02 CAD en total) y es una resolución de un tribunal, no jurisprudencia vinculante. Pero el principio se extiende: lo que dice y hace tu agente es responsabilidad tuya.

Así que la pregunta para el proveedor es concreta: muéstrame la lista de permisos y muéstrame qué pasa antes de que se ejecute algo irreversible.

Esto es lo que documentan los proveedores:

• Gorgias tiene un buen valor por defecto. Para acciones irreversibles "like canceling an order or skipping a subscription, Customer confirmation is turned on automatically," y desactivarlo implica confirmar que lo entiendes, según su documentación de acciones. Más en nuestro desglose de las acciones del Gorgias AI Agent.
• HubSpot da a cada acción del agente de cliente un nivel de protección None, Match email o Verify email, y aconseja que los cambios de acceso a la cuenta envíen enlaces seguros en lugar de actuar directamente, según su guía de configuración. Nuestra guía de barreras de Breeze cubre el lado de la escalación.
• Salesforce hace que los agentes "respect standard Salesforce access controls," y las acciones personalizadas heredan los permisos del flow o la clase Apex que hay detrás, según Trust and Agentforce. Potente, pero significa que tu higiene de permisos de Salesforce es ahora tu higiene de permisos de IA.
• Freshworks dice que su agente "stays within predefined flows," según el marco de confianza de Freddy AI. Pregunta cómo se ve eso en la pantalla de administración.

Fíjate en las dos formas distintas: Gorgias y HubSpot piden confirmar al cliente, mientras que una cola de aprobación humana lo pide a tu equipo. La confirmación del cliente detiene a un atacante que no es el titular de la cuenta. No impide que el agente tome una mala decisión que el cliente real acepta encantado, como un reembolso fuera de política. Para las acciones que mueven dinero querría a una persona de tu equipo en el circuito, al menos durante los primeros meses. Nuestra guía de flujos de aprobación en soporte profundiza en dónde poner el límite.

Esta es la parte de eesel sobre la que tengo más opinión. Cada acción es un permiso, configurado por agente como Auto, Requiere aprobación o Desactivada, y la documentación de acciones y aprobaciones recomienda mantener "refunds, cancellations and anything that costs money behind an approval." Las aprobaciones nunca se ejecutan solas tras un tiempo de espera, los Viewers no pueden aprobar y cada aprobación registra quién decidió y cuándo.

Un revisor debería comprobar aquí dos cosas más. Primero, las credenciales: en eesel, las solicitudes salientes van solo a los dominios que has permitido en Network Access, y la cabecera de autenticación se añade en el servidor, de modo que "a manipulated agent can't read out a key or token because it never had one." Segundo, cualquier otra vía de entrada. eesel tiene una CLI (npx @eesel/cli) que permite a una persona, un script o un agente de código como Claude Code o Cursor chatear con el compañero, subir conocimiento, conectar automatizaciones y vaciar la cola de aprobaciones con eesel approvals. Cada espacio de trabajo es además un servidor de Model Context Protocol. El punto de seguridad es que las escrituras por CLI y MCP "follow the same action permissions as everything else," así que una acción retenida sigue retenida sin importar por qué puerta entró. Haz la misma pregunta a cada proveedor sobre su API.

El alcance importa tanto como los permisos. Adverscale, que ayuda a personas con solicitudes de pasaporte de EE. UU., ejecuta su agente de Zendesk solo cuando una persona escribe @eesel en una nota interna, y "She never decides a refund." XAP, una empresa de software educativo que trabaja con estados y universidades de EE. UU., pone un filtro delante de su agente de Freshdesk para que solo pasen los casos de derivación y los restablecimientos de contraseña del portal.

¿Puede un correo de un cliente convencer al bot de hacer algo?

Potencialmente sí, y los buenos proveedores lo dicen en lugar de afirmar inmunidad. OWASP lista la inyección de prompts como el riesgo número uno y señala que las instrucciones inyectadas "do not need to be human-visible/readable, as long as the content is parsed by the model." Para un agente de soporte, eso significa texto blanco en un correo, una línea en un PDF adjunto o un artículo de ayuda envenenado. OWASP también señala que la generación aumentada por recuperación y el ajuste fino "do not fully mitigate" el problema. Nuestra entrada de glosario sobre inyección de prompts tiene la versión en lenguaje sencillo.

Lo que documentan los proveedores:

• Freshworks analiza las entradas con "Azure AI Content Safety and Prompt Shields" (marco de confianza de Freddy AI).
• Salesforce tiene "Prompt Defense," descrito como políticas del sistema más detección de inyección de prompts (Trust and Agentforce).
• Front lista un informe "Front AI Pentest 2026" en su centro de confianza, que es exactamente el tipo de documento que pediría a todos los proveedores.
• Zendesk, HubSpot, Gorgias y Help Scout no describen una defensa contra la inyección de prompts en las páginas que revisé. Eso no significa que no exista ninguna. Significa que tienes que preguntar.

La respuesta honesta es que los filtros reducen el riesgo y los permisos limitan el daño. La FAQ de seguridad de eesel lo dice bien: "the protection isn't that the model can't act. It's that what it can act on is bounded, and you set the bounds." Una acción que no has activado no está disponible para el modelo en absoluto, diga lo que diga un correo. Si quieres probarlo tú mismo antes de firmar, nuestra guía de pruebas adversarias tiene prompts de prueba que merece la pena intentar.

Los datos sensibles son el riesgo hermano. La Sensitive Information Disclosure de OWASP abarca datos personales, detalles financieros, historiales médicos y credenciales. La trampa que más veo es suponer que el enmascaramiento de datos personales del proveedor cubre al agente de IA. Salesforce es refrescantemente claro aquí: el enmascaramiento basado en patrones y en campos "is disabled for agents," y su FAQ de privacidad dice que es "to improve performance and accuracy of agents" (Data Masking Limitations in Agentforce). La redacción automática y el enmascaramiento de Zendesk están en su complemento ADPP para planes Enterprise.

Me aplicaré el mismo estándar a eesel. Nuestra redacción de datos personales cubre 15 categorías (tarjetas, números de seguridad social, datos bancarios, claves de API, nombres, direcciones y más) en tickets pasados antes de almacenarlos o indexarlos, y falla de forma cerrada: los tickets que no puede redactar se omiten, no se indexan en bruto. Pero es opcional por integración, está desactivada por defecto en espacios de trabajo más nuevos y no se aplica a conversaciones en vivo. Cuando el agente obtiene un ticket en vivo para redactar una respuesta, el ticket sin redactar llega al modelo. Si eso te importa, pertenece a la conversación sobre el DPA. Nuestra guía sobre redactar datos personales en transcripciones de soporte cubre más opciones.

¿Puedes ver cada respuesta y acción después?

Un registro de auditoría es lo que convierte "creemos que el agente se portó bien" en "esto hizo en el ticket 4,812 y por qué." También es el elemento que más falta específicamente para la IA. El registro de auditoría general de administración es común. Un registro de lo que hizo la IA, no:

• El registro de auditoría de Front está en todos los planes, pero sus fuentes listadas son Admin Copilot, API, Applications, SCIM y Teammates. Autopilot no es una de ellas.
• El historial de actividad de HubSpot "only records HubSpot-user based actions."
• El registro de auditoría de Zendesk es para planes Enterprise y superiores. Para Custom Agents, Zendesk dice que muestra "how an agent arrived at its responses or decisions."
• Salesforce registra prompts, respuestas y señales de confianza en Data 360, con un rastro de auditoría en Enterprise y superiores con un complemento de Einstein. El más completo de los siete sobre el papel.
• Gorgias te permite "view every single answer AI Agent sends, including the knowledge sources it pulls from," según su FAQ.

En eesel, Activity lista cada ejecución en todos los canales: qué la activó, qué conocimiento leyó, qué acciones realizó y su razonamiento. Puedes filtrar por aprobadas, rechazadas y pendientes.

La visibilidad antes del lanzamiento importa tanto como después. La revisión más segura que he visto termina con el agente ejecutándose sobre tus propios tickets resueltos, sin enviar nada, de modo que tu equipo de seguridad y tus responsables de soporte juzguen respuestas reales en lugar de un guion de demo. El informe de simulación de eesel hace esto con 20 tickets resueltos recientemente, y nuestras guías sobre probar un agente de IA antes del lanzamiento y ejecutar un piloto de soporte con IA explican el resto. También es la mejor defensa contra las alucinaciones de la IA: el agente de XAP "never invents a URL, a fee, a date or a policy," y deja un marcador para el equipo cuando no puede fundamentar un detalle.

¿Cómo se comparan los 7 proveedores de helpdesk sobre el papel?

Aquí está el lado documental en una tabla, tomado del centro de confianza, el DPA y la documentación de ayuda de cada proveedor, revisado el 20 de octubre de 2026. "Not stated" significa que no lo encontré en las páginas públicas, no que no exista.

Dos líneas de esa tabla merecen una segunda mirada. Primero, los plazos de brecha. El artículo 33 del GDPR te da a ti, como responsable, 72 horas para notificar al regulador, pero solo pide al encargado que te avise "without undue delay." Si el contrato de tu proveedor dice lo mismo, tu reloj de 72 horas puede empezar antes de que siquiera lo sepas. Pide un número en horas.

Segundo, HIPAA. Que Help Scout exija un AI Feature Healthcare Addendum aparte es en realidad un buen patrón, porque obliga a plantear la pregunta que muchos compradores del sector salud olvidan: ¿el BAA cubre la IA o solo la bandeja de entrada? Nuestra guía de IA compatible con HIPAA y el artículo de atención al cliente con IA para salud van más a fondo. Si usas específicamente uno de estos helpdesks, también hemos escrito con más detalle sobre seguridad y cumplimiento de Zendesk, SOC 2 de Freshdesk y SOC 2 de Gorgias.

Una ley más para tener en la lista. El artículo 50 de la Ley de IA de la UE exige que los sistemas de IA que hablan con personas les digan que hablan con una IA, salvo que sea evidente, y ese deber se aplica desde el 2 de agosto de 2026. Si atiendes a clientes de la UE, comprueba que el proveedor te deja configurar ese aviso.

¿Cómo haces la revisión sin frenar el proyecto?

Las revisiones de seguridad de herramientas de IA suelen morir en una cola, no en un "no". Este es el orden en que yo la haría, que suele caber en dos semanas:

1. Pide el paquete el primer día. Informe SOC 2 o calendario de auditoría, DPA, lista de subencargados y un CSA AI-CAIQ o SIG Lite completado. Un proveedor que tarda una semana en enviarlos te está diciendo algo.
2. Repasa los 10 puntos críticos de arriba en una llamada. Entrenamiento, aprendizaje entre clientes, retención, proveedores de modelos, permisos por acción, aprobaciones para mover dinero, inyección de prompts, el registro de acciones, alcance de SOC 2. Consigue las respuestas por escrito después.
3. Dibuja la ruta de los datos para tu región. Traza los cinco saltos del diagrama de arriba con las respuestas reales del proveedor. Las excepciones de residencia aparecen aquí.
4. Empieza el agente en modo borrador. Solo notas internas, nada se envía a los clientes. Timengo, un proveedor danés de correo seguro cuyos clientes incluyen municipios y escuelas, ejecuta eesel así en Freshdesk: "The engineer sends; eesel does not."
5. Amplía los permisos una acción cada vez. Observa el registro, luego pasa el etiquetado a automático, luego las primeras respuestas, y mantén los reembolsos con aprobación el mayor tiempo posible.

Si aún estás decidiendo si comprar siquiera, construir o comprar IA para soporte cubre la vía interna, y cómo cambiar de proveedor de soporte con IA ayuda si reemplazas uno que no superó una revisión. Nuestro scorecard de piloto de soporte con IA convierte el paso 4 en números de aprobado o suspenso.

Prueba eesel con tu lista de seguridad en la mano

Si tu equipo va a hacer esta revisión sobre un agente de IA para Zendesk o Freshdesk, hazla también con eesel. eesel es un compañero de IA para helpdesk que se une a tu cola existente en Zendesk, Freshdesk y otros helpdesks, con cada acción en una lista de permisos que tú controlas y cada ejecución registrada con su razonamiento. smava, un comparador de finanzas de consumo, ejecuta agentes de eesel acotados para dos marcas en un mismo Zendesk, donde "Each agent has one job and a list of things it must never do."

El centro de confianza tiene nuestro estado actual, y el paquete de seguridad (políticas, DPA, respuestas CAIQ o SIG Lite) está disponible bajo petición con NDA, normalmente en un día laborable. También puedes empezar gratis con 100 créditos en la página de precios y ejecutar una simulación con tus propios tickets pasados antes de que nadie firme nada. Prueba eesel.