Nesta página
Trust Center de Fhinck
Cómo protegemos los datos de su operación: controles, evidencias, evaluaciones independientes y documentos, en un solo lugar.
Última actualización: octubre de 2026
Visión General de Seguridad
Fhinck adopta un enfoque de Defense in Depth, implementando múltiples capas de controles de seguridad en toda nuestra infraestructura, aplicaciones y procesos operacionales.
Zero Trust
Privacy by Design
Minimización de Datos
Defensa en profundidad
Transparencia
Infraestructura en la Nube
Alojamiento seguro y certificado
Google Cloud Platform (GCP)
Región: Google Cloud, procesamiento principal en EE. UU.
Certificaciones del GCP:
- ISO 27001 / 27017 / 27018: Gestión de seguridad de la información, seguridad en la nube y protección de datos personales
- SOC 2 Type II: Controles de seguridad, disponibilidad y confidencialidad — auditados por terceros independientes
- PCI DSS Nivel 1: Estándar internacional para la protección de datos de pago
- FedRAMP / C5 / HIPAA: Certificaciones del gobierno de EE. UU., BSI alemán y sector sanitario
- GDPR/LGPD Compliant: Cláusulas de protección de datos personales
SLA y Disponibilidad:
SLA GCP: 99,95%
Compromiso Fhinck: 99,5%
El compromiso de 99,5% es deliberadamente conservador: queda por debajo del SLA de 99,95% de la infraestructura de GCP porque reserva margen para la capa de aplicación — deploys y ventanas de mantenimiento — en lugar de presentar el techo de la nube como si fuera el de toda la plataforma.
Arquitectura Serverless:
- Cloud Functions & Cloud Run
- Escalabilidad automática
- Parches de seguridad automáticos
Bases de Datos Seguras
BigQuery (Data Warehouse):
- • Cifrado AES-256 en reposo
- • Controles de acceso granulares
- • Auditoría completa de consultas
Firestore (NoSQL):
- • Cifrado automático
- • Reglas de seguridad personalizadas
Segregación de Entornos
Desarrollo
Datos sintéticos o anonimizados
Staging
Pruebas preproducción aisladas
Producción
Entorno protegido y monitorizado
Cifrado
Cifrado en Tránsito
TLS 1.2+ (1.3 preferente)
- Todas las comunicaciones mediante HTTPS
- Certificados SSL/TLS gestionados y renovados automáticamente — sin intervención manual, sin riesgo de expiración, con verificación continua
- Configuración reforzada (sin cifrados débiles)
- HSTS (HTTP Strict Transport Security)
Cliente → TLS 1.3 → Load Balancer → Internal TLS → Backend
Cifrado en Reposo
AES-256 (Advanced Encryption Standard)
- Datos almacenados cifrados en BigQuery
- Copias de recuperación cifradas en reposo (AES-256, gestionado por GCP)
Gestión de Claves:
- • Secretos en Google Secret Manager, con escaneo automático de secretos en el código
- • Cifrado at-rest gestionado por GCP (AES-256, claves de Google)
- • Aislamiento por cliente: dataset de BigQuery dedicado
Hash de Contraseñas:
Firebase Auth (scrypt) - hashing de contraseñas gestionado, resistente a ataques de fuerza bruta
Seudonimización y Anonimización
Opciones disponibles para clientes:
Seudonimización
ID reemplazado por hash único
Anonimización Completa
Eliminación de identificadores personales
Agregación
Solo datos agregados
Controles de Acceso y Autenticación
Autenticación Multifactor (MFA)
Obligatoria para todos los accesos críticos:
Single Sign-On (SSO)
Integraciones Disponibles:
- SAML 2.0: Estándar enterprise
- OIDC: Protocolo moderno de identidad
- Google, Azure AD, Okta, Auth0
Beneficios:
- Gestión centralizada de identidades
- Credenciales únicas para múltiples sistemas
- Políticas de contraseña corporativas aplicadas
- Revocación instantánea de acceso
Control de Acceso Basado en Roles (RBAC)
Perfiles granulares en el Dashboard:
Visualizador
Acceso solo lectura
Analista
Creación de informes
Gestor
Acceso al departamento
Administrador
Gestión completa
Auditor
Acceso a logs
Principio de Mínimo Privilegio: Cada usuario recibe únicamente los permisos necesarios para sus funciones.
Desarrollo Seguro de Software
SAST
Análisis Estático de Código
- • ESLint Security Plugin
- • Semgrep (OWASP/CWE)
- • Gitleaks (secretos)
DAST
Análisis Dinámico de Aplicaciones
- • OWASP ZAP
- • Escaneo baseline (pasivo), semanal
Vulnerabilidades
Gestión Proactiva
- • npm audit (diario)
- • Trivy (diario: dependencias e infraestructura como código)
- • OWASP ZAP (semanal: escaneo dinámico)
Plazos de Corrección de Vulnerabilidades
CRÍTICAS
< 48h
ALTAS
< 10 días
MEDIAS
< 30 días
BAJAS
< 90 días
Evaluación de Seguridad Web
Frecuencia
Mensual
Última Ejecución
Septiembre 2026
Resultado
✓ Ninguna vuln. crítica
Privacidad y Protección de Datos
Cumplimiento LGPD
Estado: Alineado con la LGPD
Funciones y Responsabilidades
Responsable: Cliente
Determina los fines y medios del tratamiento
Encargado: Fhinck
Procesa datos conforme a instrucciones del Responsable
DPO: Michel Zarzour Filho
dpo@fhinck.com
(11) 98367-3803
Minimización de Datos
✓ Recopilamos
- • ID de usuario, hostname
- • Metadatos de apps
- • Tiempos de actividad
✗ NO Recopilamos
- • Capturas de pantalla en segundo plano
- • Lectura de archivos
Respuesta a Incidentes de Seguridad
Proceso de Respuesta
Detección
0–2 horas
Contención
2–8 horas
Notificación
Hasta 48h
Resolución
Pos-incidente
Equipo de Respuesta a Emergencias (ERT)
Auditorías y Cumplimiento
Auditorías Internas
Cumplimiento y referencias
Cumplimiento LGPD
Alineado
Marco Civil da Internet
Conforme
OWASP Top 10
Mitigaciones implementadas
Por qué conformidad continua
Seguridad que evoluciona con la operación — no una foto anual
Controles continuos, no una vez al año
El análisis estático de seguridad y la verificación de dependencias se ejecutan todos los días, y el escaneo dinámico, cada semana, durante todo el año. La evidencia siempre actualizada vale más que un certificado emitido en un único día.
AI-first: los procesos cambian constantemente
Con IA, los flujos y la arquitectura evolucionan de forma continua. Una certificación ligada a un alcance congelado envejece en meses. Nuestra gobernanza acompaña el cambio en lugar de frenarlo.
Inversión directa en protección real
En lugar de destinar presupuesto al ciclo de auditoría/certificación, Fhinck invierte directamente en controles, monitoreo en tiempo real y evaluación automatizada mensual de seguridad web (Beagle Security) — protección donde genera resultados reales.
Matriz de Controles de Seguridad
Vista estructurada de los 10 dominios de control y de cómo opera cada uno hoy
Seguridad para una operación AI-first
Los frameworks de arriba, SOC 2 e ISO/IEC 27001, describen controles diseñados para una operación humana, y Fhinck está alineada con ellas. Pero Fhinck opera con agentes de IA. Para una plataforma AI-first, los parámetros que realmente importan son los definidos por los estándares específicos de IA: el NIST AI Risk Management Framework, la ISO/IEC 42001 (gestión de IA) y el OWASP Top 10 para LLM y para Aplicaciones Agénticas. A continuación, los riesgos que esos marcos clasifican como críticos para sistemas de IA — y cómo Fhinck atiende cada uno, con evidencia en su propio repositorio.
El enfoque AI-first
Una auditoría tradicional pregunta “¿hay un humano aprobando esto?”. En una operación agéntica la pregunta correcta es “¿qué impide que el agente actúe por su cuenta — y eso es comprobable?”.
Defensa contra prompt injection y jailbreak
Defensa activaEstándar de referencia: OWASP LLM01:2025 · Agentic ASI01
Toda entrada que llega a un modelo puede intentar secuestrar sus instrucciones. Tratamos la entrada del usuario como no confiable.
Cómo lo cumple Fhinck
Copiloto del dashboard: detección determinista de inyección y jailbreak en portugués e inglés (override de instrucción, role-hijack, intento de extraer el system prompt, token smuggling), tope de 4.000 caracteres, eliminación de HTML/script y rate-limit adversarial dedicado por sesión. El pipeline de backend aplica su propia defensa (sandwich defense).
Guardrails de salida y anti-fuga
Defensa activaEstándar de referencia: OWASP LLM02 · LLM05 · LLM07
Ninguna respuesta de IA sale sin filtro contra fuga de datos personales, de otro cliente o del propio sistema.
Cómo lo cumple Fhinck
El filtro de salida redacta CPF, CNPJ, correo externo, tarjeta, teléfono y tokens; un canary token descarta toda la respuesta si hay señal de extracción del system prompt. En el agente de soporte, 15 patrones deterministas de fuga (datasets de cliente, IDs internos, nombres de tabla y de workflow) detienen la ejecución.
Harness y contrato de comportamiento del agente
Bloqueo por hookEstándar de referencia: OWASP LLM06 · Agentic ASI02/ASI03
El riesgo nº 1 de los sistemas agénticos es la "agencia excesiva". Cada agente opera bajo un contrato mecánico, no bajo confianza en el modelo.
Cómo lo cumple Fhinck
Los subagentes solo se ejecutan cuando: las skills declaradas fueron realmente invocadas, las afirmaciones cuantitativas llevan evidencia estructural (archivo:línea o salida) y existe un artefacto persistente — reglas C1–C4 verificadas por un hook que bloquea la llamada. El límite de briefing también se aplica mediante un hook que bloquea la llamada.
Aprobación humana para acciones críticas
Bloqueo por hookEstándar de referencia: OWASP Agentic ASI09 · NIST AI RMF
Una acción destructiva o en producción nunca ocurre solo porque el agente lo decidió.
Cómo lo cumple Fhinck
Los comandos críticos (deploy en producción, DROP/TRUNCATE, force-push, borrado en la nube) exigen un código de un solo uso (TOTP) + una firma criptográfica verificada offline, o un artefacto de Triple Gate del día. Las freeze windows bloquean el deploy en horario de cliente y todo bypass genera traza de auditoría.
Red-team adversarial y LLM-as-judge continuos
ContinuoEstándar de referencia: NIST AI RMF (MEASURE) · MITRE ATLAS
A los agentes se les ataca a propósito y se les juzga por calidad antes de cualquier promoción.
Cómo lo cumple Fhinck
Framework interno de auditoría de agentes con 33 casos adversariales (prompt injection, bypass de confirmación, abuso de permisos). Los cambios en el pipeline de soporte solo se promueven tras un gate de LLM-as-judge en 4 dimensiones (acción, calidad, compliance, efectividad) con nota mínima 4,5/5, sobre una suite sintética y tickets reales sanitizados.
Observabilidad de cada run de agente
En producciónEstándar de referencia: OWASP Agentic ASI10 · NIST AI RMF
La decisión de un agente no puede ser una caja negra: debe ser auditable después.
Cómo lo cumple Fhinck
Canal único de telemetría en formato OTel GenAI en BigQuery (decisiones de hook, runs de agente, deploys, hallazgos de auditoría), con redacción automática de PII y retención de 365 días; log append-only de invocación de skills usado para enforcement.
Aislamiento entre clientes y radio de impacto contenido
Aislamiento estructuralEstándar de referencia: OWASP LLM02:2025 · NIST AI RMF (MANAGE)
En una operación agéntica, el dato de cada cliente queda en su propio dataset y cada consulta se limita a un único cliente, lo que reduce el radio de impacto de una falla.
Cómo lo cumple Fhinck
Cada cliente vive en un dataset de BigQuery dedicado y toda consulta es delimitada y saneada por empresa antes de tocar el dato — el identificador de la empresa se valida y se fija en la ruta de la tabla, sin consultas cross-cliente. Las credenciales de servicio siguen el menor privilegio.
Equivalencia de controles AI-First
El mismo objetivo de cada control, cumplido de forma nativa de IA
Por qué no buscamos el sello
SOC 2 e ISO 27001 fueron escritas para una empresa donde cada control lo ejecuta y aprueba una persona. Fhinck opera por IA: el sello certificaría procedimientos humanos que no describen cómo operamos realmente. Cumplimos el objetivo de cada control — solo no ejecutamos la actividad en la forma humana que la norma presume.
Objetivo vs. actividad
Toda norma tiene dos capas: el objetivo del control (lo que protege) y la actividad prescrita (el procedimiento humano). Fhinck entrega cada objetivo mediante mecanismos de máquina — auditables y continuos.
Lo que la norma presume — operación humana
Cómo lo cumple Fhinck — operación por IA
A.6.1 · Verificación de antecedentes
Lo que la norma presume — operación humana
RR.HH. investiga el historial de una persona contratada.
Cómo lo cumple Fhinck — operación por IA
Evaluación y red-team del modelo + comportamiento fijado en un system prompt versionado y auditable.
A.6.3 · Capacitación y concienciación
Lo que la norma presume — operación humana
El empleado realiza capacitación de seguridad periódica.
Cómo lo cumple Fhinck — operación por IA
Guardrails y sanitización contra prompt injection — el comportamiento seguro se codifica, no se entrena persona por persona.
CC5 · Segregación de funciones
Lo que la norma presume — operación humana
Dos personas distintas: nadie aprueba su propio trabajo.
Cómo lo cumple Fhinck — operación por IA
Gates automáticos + modelo de autonomía × riesgo: la acción de mayor impacto no se ejecuta sin verificación independiente.
CC6 / A.5.15–18 · Acceso por identidad
Lo que la norma presume — operación humana
Usuario humano con MFA; aprovisionamiento y offboarding por RR.HH.
Cómo lo cumple Fhinck — operación por IA
Identidad de máquina con responsable nombrado, mínimo privilegio, tokens de acceso de corta duración y baja por ciclo de vida.
CC8 / A.8.32 · Gestión de cambios
Lo que la norma presume — operación humana
Un segundo humano revisa y aprueba cada cambio.
Cómo lo cumple Fhinck — operación por IA
Freeze + snapshot + rollback + gate automático en cada deploy, con traza de auditoría completa.
Processing Integrity · Integridad de procesamiento
Lo que la norma presume — operación humana
Proceso determinista, verificable paso a paso.
Cómo lo cumple Fhinck — operación por IA
Human-in-the-loop obligatorio en acciones con efecto colateral + registro de auditoría de las decisiones de IA.
CC7 / A.8.15 · Operación y logging
Lo que la norma presume — operación humana
Analista de guardia monitorea y registra eventos.
Cómo lo cumple Fhinck — operación por IA
Observabilidad en tiempo real (Cloud Logging + BigQuery), auditable por máquina y siempre actual.
Lo que el sello ni pregunta
Donde la operación por IA introduce riesgos que estas normas — anteriores a la era agéntica — ni siquiera abordan (autonomía y radio de impacto, inyección de prompt, identidades de máquina), aplicamos gobernanza específica y mapeo al OWASP LLM Top 10. Aprobar un audit pre-agéntico no cubre esos riesgos; nosotros sí.
Para equipos de seguridad y procurement
La pregunta que importa en una evaluación de proveedor no es "¿tiene el sello?" — es "¿puede probar sus controles?". Respondemos de dos formas:
Infraestructura ya certificada por un tercero
Toda la base corre en Google Cloud Platform — SOC 2 Type II e ISO 27001, auditada de forma independiente. La capa de infraestructura que necesita validar ya tiene atestación formal.
Respondemos su cuestionario
Completamos cuestionarios de seguridad de proveedor (SIG, CAIQ o su formato) directamente, control por control.
SOC 214
Fhinck se alinea con los controles de este framework, pero NO posee ni busca la certificación SOC 2.
Los controles de seguridad de Fhinck están alineados con los Trust Services Criteria de SOC 2. Nuestra infraestructura base (Google Cloud Platform) está certificada SOC 2 Type II. Estado honesto por criterio y por Common Criteria a continuación.
ISO 2700113
Fhinck se alinea con los controles de este framework, pero NO posee ni busca la certificación ISO 27001.
Los controles técnicos y organizativos de Fhinck están alineados con el Anexo A de ISO/IEC 27001:2022 (93 controles en 4 temas). Estado honesto por tema y por controles representativos a continuación.
Documentos
Los documentos públicos se descargan directamente. Los marcados como restringidos contienen información interna: solicite acceso con su correo corporativo y reciba un código de un solo uso.
Consolidación de las Políticas y Prácticas Institucionales (CPP)
PDF · ~11,5 MB
Documento maestro que reúne la Política de Seguridad de la Información, gestión de accesos, criptografía, respuesta a incidentes, continuidad del negocio y el programa de privacidad (LGPD). Versión revisada con control de versiones formal.
Informe de Auditoría Interna — Octubre/2025
PDF · ~373 KB
Resultado de la auditoría interna de seguridad y privacidad realizada en octubre de 2025, cubriendo controles de acceso, criptografía, continuidad y tratamiento de datos.
Acuerdo de Confidencialidad (NDA mutuo)
PDF · ~219 KB
Plantilla de NDA mutuo de Fhinck para el intercambio de información confidencial durante la evaluación y la ejecución de los servicios. Documento base para firma entre las partes.
Subencargados
Proveedores que tratan datos en nombre de Fhinck, los mismos declarados en nuestra Política de Privacidad.
| Proveedor | Finalidad | Ubicación |
|---|---|---|
| Google Cloud Platform | Infraestructura en la nube: procesamiento y almacenamiento de los datos de la plataforma | Estados Unidos (región principal) |
| Proveedores de IA generativa | Modelos de lenguaje usados en las funciones de IA de la plataforma, con protecciones contractuales | — |
| Herramientas de análisis y observabilidad | Observabilidad y análisis de uso de la plataforma | — |
| Google reCAPTCHA Enterprise | Protección contra envíos automatizados en los formularios del sitio | — |
La lista nominal de subencargados, con finalidad y país, puede solicitarse al DPO en dpo@fhinck.com.
Actualizaciones de seguridad
Lo que cambió recientemente en nuestra postura de seguridad.
Oct/2026
Trust Center abierto al público
Controles, evidencias y evaluaciones independientes quedan abiertos a cualquier visitante. Los documentos con información interna siguen disponibles bajo solicitud de acceso.
Sep/2026
Superficie externa reforzada
Registro DNS que define qué autoridades pueden emitir certificados para fhinck.com, acceso SSH a las máquinas de automatización restringido a un túnel autenticado y revisión de los registros DNS. El 28/09 SecurityScorecard registró nota A, con 100 en los 10 factores evaluados.
Sep/2026
Evaluación automatizada de seguridad web
Ronda mensual de Beagle Security el 11/09: riesgo clasificado como bajo y ninguna vulnerabilidad crítica.
Jun/2026
Controles mapeados a SOC 2 e ISO 27001
Estado por criterio publicado en esta página, con evidencia por control. Fhinck está alineada con estos estándares, sin certificación.
Divulgación responsable de vulnerabilidades
¿Encontró una posible vulnerabilidad en un sistema de Fhinck? Queremos saberlo. La investigación de buena fe que siga esta política es bienvenida.
Cómo reportar
- 1Envíe a security@fhinck.com la descripción, los pasos para reproducir y el impacto observado.
- 2Confirmamos la recepción en hasta 48 horas y lo mantenemos informado hasta la corrección.
- 3Le pedimos mantener el hallazgo en reserva hasta la corrección o durante 90 días, lo que ocurra primero.
Alcance
fhinck.com y sus subdominios, el dashboard y la API de la plataforma.
Fuera de alcance
Denegación de servicio, ingeniería social, acceso físico, spam y cualquier acceso, alteración o retención de datos de clientes más allá del mínimo necesario para demostrar el problema.
Puerto seguro
La investigación de buena fe realizada dentro de esta política se considera autorizada y Fhinck no tomará acciones legales contra ella. No hay programa de recompensa en dinero.
El mismo contacto está publicado en fhinck.com/.well-known/security.txt, según el estándar RFC 9116.
Contacto y Soporte
Emergencias
Equipo ERT
24/7 para incidentes críticos
Compromiso Final
La seguridad y privacidad de los datos de nuestros clientes y usuarios son prioridades absolutas de Fhinck. Invertimos continuamente en tecnología, procesos y personas para mantener los más altos estándares de protección.
Última actualización: Octubre de 2026