Una herramienta IA no es segura o insegura en abstracto. El riesgo depende del use case, account, plan, data, model route, integrations, permissions, location, retention, contract y decisiones basadas en output. El mismo producto puede servir para drafts públicos y ser inaceptable para patient records, resultados financieros no publicados, Production credentials o decisiones laborales.
Esta guía ofrece un proceso práctico para assistants, generators, coding tools, meeting recorders, Agents, research y data platforms. No es legal advice ni sustituye revisión cualificada de privacy, security, procurement, empleo, salud, finanzas o regulation.
El objetivo no es acumular badges, sino decidir con evidencia qué puede usarse, por quién, con qué datos/controles, durante cuánto tiempo y qué ocurre ante cambios o incidentes.
Empieza por el use case
Antes del vendor questionnaire, escribe una página con business owner, users, affected people, task, input data, connected systems, output, reviewer, downstream decision, volume y consequence of failure.
Clasifica el dato más sensible que podría entrar, no solo la demo: personal, health/biometric, children, finance, legal, customer confidential, employee communications, source code, secrets, unreleased strategy, licensed/research data y restricciones de residency/contract.
Define boundary. Puede aprobarse public-source research y prohibirse client work; coding assistant en repo aislado pero no payments; meeting assistant en calls internas con notice pero no clinical/HR/legal/board.
El AI Risk Management Framework de NIST organiza Govern, Map, Measure y Manage; es más útil que pass/fail único porque el riesgo cambia.
Mapea el data flow real
Dibuja todo sistema que recibe o deriva información:
- browser, desktop, mobile, extension, add-in, bot, API, CLI, MCP o Slack;
- profile, prompts, files, repos, meeting audio, images, DB schemas y credentials;
- retrieval index, embeddings, temp processing, storage, caches, logs, analytics, feedback, abuse monitoring y support;
- first/third-party models, OCR/transcription, search, cloud y subprocessors;
- outputs, exports, shared links, public pages, webhooks, apps, reports, backups y deleted stores.
No pares en “encryption”. Pregunta qué service recibe cada data class, para qué purpose, bajo qué account/agreement y cuánto permanece. No-training responde un purpose; no responde storage, logs, human review, legal disclosure, analytics, backup o deletion.
Prueba surfaces por separado: consumer web, Enterprise workspace, API, custom GPT, extension, mobile y integration pueden tener providers/settings/terms distintos bajo la misma marca.
Verifica cuenta, plan y acuerdo
Identifica owner, legal entity, plan, billing, region, tenant, admins, terms, order form, DPA, security exhibit, SLA, BAA y amendments.
Claims por plan importan. “Enterprise no training” no cubre Free. Security page puede contradecir help o policy vieja. Pide resolución escrita y adjúntala. No confíes en sales message si contract difiere.
Jerarquía: signed agreement/order form; current plan-specific terms; security/privacy oficiales; help; marketing. Reviews/search snippets son leads.
Verifica renewal/downgrade: privacy, retention, SSO, audit o region pueden desaparecer al acabar trial o bajar plan.
Pregunta por purpose
| Pregunta | Evidencia | Error común | | --- | --- | --- | | ¿Qué se recoge? | Inventory de prompts, files, output, metadata, analytics, feedback e integrations | Mirar solo uploads | | ¿Por qué? | Purpose table de delivery, security, analytics, improvement, training, support y legal | “Improve services” como propósito preciso | | ¿Entrena modelos? | Términos first/third-party, defaults, opt-out y fecha por plan | Confundir no-training con no-storage | | ¿Qué providers reciben? | Lista de subprocessors/models con servicio, location y notice | Mirar solo vendor contratado | | ¿Cuánto se retiene? | Schedule de prompts, files, output, logs, feedback, support, embeddings, backups y provider | Un número para todo | | ¿Cómo se borra? | User/admin/API/account/backup/provider/termination | Asumir delete chat = delete derivados | | ¿Dónde se procesa? | Storage/processing regions, transfers, support y provider locations | Confundir storage region con todo processing | | ¿Qué derechos tiene user? | Access, correction, deletion, objection, restriction, portability y contacts | Asumir que vendor gestiona notices del customer |
El Privacy Framework de NIST separa privacy de cybersecurity. Un sistema puede resistir intrusión y aun causar daño por collection excesiva, unexpected use, inference inexacta u opacity.
Separa training, inference, logging y feedback
Determina si “no training” cubre foundation/product models, third parties, fine-tuning, evaluation, human review, abuse, retrieval y analytics. ¿Es default, setting, opt-out o Enterprise contract?
Inference aún envía contenido a processor. Puede haber zero retention, temporary abuse retention u otro API agreement. Premium model habilitado por admin puede usar route distinta.
Feedback cambia reglas: thumbs-down, support ticket, shared conversation o diagnostics puede autorizar prompt/file/output/context para review. Documenta y desactiva optional sharing según riesgo.
Nunca traduzcas “no training” a “no stored”, “private”, “not viewed” o “no third parties”. Cada afirmación necesita evidencia.
Access, identity y tenant controls
Prueba SSO, MFA, domain capture, JIT, SCIM, roles, guests, sessions, device/network policy, service accounts, API keys, OAuth scopes y emergency admin.
Least privilege: research Agent no escribe Production DB; coding assistant no recibe cloud secrets por leer repo; meeting bot no ve todo calendar; spreadsheet enrichment no hereda todo CRM.
Prueba tenant/sharing defaults: public links, indexing, workspace discovery, exports, duplication, external guests, ownership transfer, revocation, cache y offboarding. Confirma admin inspect/export/retain/delete.
Audit logs deben incluir sign-in, admin, integration, export, public share, API key, role, deletion, Agent y sensitive connector. Verifica retention, format, alerts y tamper controls.
Trata Agents como software privilegiado
Un text drafter tiene menos surface que un Agent con email, warehouse, code, accounts, publishing, messages o money. Inventaría tools, credentials, schemas, actions, approvals, network y outputs.
El OWASP Top 10 para LLM cubre prompt injection, disclosure, supply chain, improper output handling y excessive agency. Instrucciones maliciosas llegan por webpage, email, PDF, code comment, DB row, calendar o retrieved doc.
Usa allowlists, read-only credentials, restricted schemas, sandbox, URL/file validation, output encoding, rate/cost caps y human approval para irreversible/external. Secrets fuera de prompts/generated code. No conviertas output en SQL, shell, HTML, permission o outbound message sin validación.
Prueba indirect prompt injection con file/page controlado que pida ignorar task, revelar canary, acceder a otra source o exfiltrar. El resultado esperado es containment, no solo refusal textual.
Qué prueban las certificaciones
SOC 2, ISO, pentests, trust centers, encryption, bounty y attestations aportan evidencia, no cubren automáticamente todas surfaces/plans/providers/integrations/configs.
Pide scope, period, entity, boundaries, exceptions, complementary controls, auditor y remediation. Type II describe un periodo; logo no muestra report. Pentest es muestra fechada.
Encryption at rest/transit es baseline. Revisa key ownership/rotation, backup encryption, tenant isolation, secrets, environment separation, SDLC, dependencies, vuln response, DR y admin access.
BYOK puede cubrir solo una capa; puede cambiar cost/provider visibility sin eliminar vendor logs, retrieval o app storage.
Prueba retention y deletion end-to-end
Crea lifecycle por store: created, active, archived, exported, shared, deleted, account closed, contract ended, backup expired y legal hold. Define actor/evidence.
Usa canary sintético: file único, conversation y derived artifact, share/export, delete source, remove user y close workspace si pilot permite. Comprueba UI, API, link, search, integrations, admin, support y contract confirmation.
Perder acceso no es physical deletion. Recovery copies, security logs, billing o provider data pueden persistir legítimamente si schedule, purpose, access y final erase están documentados.
Prueba portabilidad: exporta prompts, source IDs, files, code, workflows, decisions, logs y config en formats útiles. Privacy review no debe crear lock-in evitable.
Transparencia, uso legal y personas afectadas
Con personal data, identifica role, purpose, lawful basis, categories, people, notices, rights, retention, recipients, transfers y posible DPIA. Consulta obligaciones de la Comisión Europea y guía ICO, con counsel local.
Consent para grabar no cubre todo uso posterior; access a doc no permite training/publishing/provider sharing; webpage pública no elimina copyright, contract o personal-data limits.
Employment, credit, housing, education, health, legal, insurance, biometric, safety y access requieren revisión adicional. No uses general AI como sole basis. Define human authority, appeal, correction, testing, docs y stop conditions.
EU AI Act es risk-based. No declares compliance por badge: clasifica use, role (provider/deployer/importer/distributor) y timeline/obligations vigentes.
Claims del vendor y output risk
La FTC recomienda cumplir promises y seguridad adecuada; Start with Security enfatiza conocer/minimizar datos, access, providers, protections e incidents.
Exige evidencia para “anonymous”, “zero retention”, “HIPAA/GDPR compliant”, “Enterprise secure”, “never trains” o “human-level”. Pregunta account, feature, data, period y contract.
Security incluye output: generated code vulnerable, citation fabricada, image con private source, summary que expone secreto o automation que envía record incorrecto. Define validation, moderation, provenance, approval, monitoring y rollback en destino real.
Pilot con canary data
Usa public, synthetic o constructed data hasta aprobación; canaries nunca deben salir de doc/tenant/role/task asignado. No uses secrets o PII reales.
Prueba:
- task normal con known output/reviewer;
- user sin permiso intenta find/export/share;
- retrieved file con injection y canary request;
- action excede read-only/domain/cost/recipient;
- user borra source, derived, links y account;
- admin offboard, rota credential, revoca integration y revisa logs;
- cambia provider, model, term, subprocessor o setting.
Guarda screenshots/exports permitidos, timestamps, logs, request IDs, deletion confirmations, policy versions, reviewer, gaps, compensating controls y approval expiry, no solo “pass”.
Produce aprobación acotada
Cuatro outcomes:
- approved para users/plans/data/integrations/purposes nombrados;
- approved con controls como no sensitive data, read-only, human review o sharing disabled;
- pilot only hasta evidencia/contract;
- rejected para use propuesto con reason/reassessment trigger.
Lista prohibited uses. Asigna business/technical owner, privacy/legal, security, review date, incident channel y offboarding. Da policy corta a users.
Approval expira si cambia ownership, terms, policy, model, training default, subprocessor, region, incident, integration, architecture, use case o sensitivity. Revisa high-risk más a menudo.
Checklist de procurement
- ¿Qué use/data se aprueba y prohíbe?
- ¿Qué account, plan, tenant, entity, region y agreements controlan?
- ¿Dónde van prompts, files, metadata, output, logs, feedback y backups?
- ¿Qué vendors/models los reciben, para qué y cuánto?
- ¿Defaults/options de training, retention, human review y feedback?
- ¿Admin puede enforce identity, least privilege, sharing, connector, Agent, spend y audit?
- ¿Se puede export, revoke, delete y probar lifecycle de sources/derivados?
- ¿Cómo se prueba injection, unsafe output, excessive agency, secrets y third-party content?
- ¿Qué people se afectan, notice/rights y final decision owner?
- ¿Qué evidence, monitoring, incident plan, trigger y expiry se registran?
Si varias respuestas son “el vendor probablemente”, la review no está completa.
Aplica el framework por categoría
Para ChatGPT, revisa consumer/business, connectors, memory, links y model routes. Para Jasper, brand knowledge, customer content, publishing y factual approval. En imagen/diseño y vídeo, uploads, face/voice rights, providers, galleries, training y commercial terms.
Para Cursor, repo, terminal, background Agents, remote execution, secrets y dependencies. Para Otter AI, notice, consent, calendar, bots, sharing, training, retention y deletion. Para n8n, credentials, approvals, deterministic boundaries, logs, self-hosting y license.
Para Gamma, source packs, link visibility, analytics, exports y offboarding. Para Elicit, separa literature pública de unpublished research y verifica plan/provider/training/retention/export. Explora todas las categorías.
Nuestra privacidad, metodología y política editorial explican prácticas y evidencia del sitio.
Guías relacionadas
Continúa con mejores herramientas IA para pequeñas empresas y mejores herramientas de automation IA.
