CompliGuard AI — MVP Explainer

Concepto

CompliGuard AI automatiza la revisión de comunicaciones corporativas (emails, chats, transcripciones de llamadas) para detectar infracciones normativas antes de que se conviertan en multas millonarias.

Las empresas financieras y de salud gastan miles de horas al año revisando manualmente comunicaciones para cumplir con GDPR, HIPAA y FINRA. CompliGuard AI resuelve este problema con un motor de análisis basado en LLM que escanea el texto, asigna un score de riesgo, y alerta al oficial de cumplimiento en tiempo real.

---

Arquitectura

┌──────────────────────────────────────────────────────────────────┐
│                         API Layer (REST)                          │
│   AuthController │ ComplianceController │ DashboardController    │
│                       CustomRuleController                        │
└───────────────────────────────┬──────────────────────────────────┘
                                │
┌───────────────────────────────▼──────────────────────────────────┐
│                       Service Layer                               │
│  AuthService │ ComplianceAnalysisService │ DashboardService      │
│              CustomRuleService │ AlertService                     │
└──────┬─────────────────┬────────────────────────────────────────┘
       │                 │
┌──────▼──────┐   ┌──────▼─────────────────────────────┐
│  JPA Repos  │   │   LlmClient (Feign → OpenAI API)    │
│  H2 / PgSQL │   │   Virtual Thread — non-blocking I/O │
└─────────────┘   └─────────────────────────────────────┘

Stack:

• Spring Boot 4.0.4 / Java 25
• Spring Security 7 — stateless JWT (jjwt 0.12.6)
• Spring Data JPA — H2 (dev) / PostgreSQL (prod)
• Spring Cloud OpenFeign 4.2.1 — LLM HTTP client
• Jackson 3.x (%%INLINE0%%) — via pre-configured %%INLINE1%%
• Virtual Threads (Thread.ofVirtual()) — LLM calls isolated from platform threads

Capas:

Capa	Paquete	Descripción
Model	model/	JPA entities: User, CommunicationLog, ComplianceFinding, CustomRule
DTO	dto/	Java 25 Records — inmutables, type-safe
Repository	repository/	Spring Data JPA interfaces
Security	security/	JwtUtil, JwtAuthenticationFilter, UserDetailsServiceImpl
Service	service/	Lógica de negocio, orquestación LLM, alertas
Client	client/	Feign interface + DTOs para OpenAI API
Controller	controller/	REST endpoints
Exception	exception/	GlobalExceptionHandler + ApiError record
Config	config/	SecurityConfig, FeignConfig, AppProperties

---

Endpoints

Autenticación (público)

Método	Path	Descripción
POST	/api/v1/auth/register	Registrar usuario, devuelve JWT
POST	/api/v1/auth/login	Autenticar, devuelve JWT

Análisis de Cumplimiento (requiere Bearer JWT)

Método	Path	Descripción
POST	/api/v1/analyze	Ingerir y analizar una comunicación
GET	/api/v1/findings?regulation=GDPR&riskLevel=HIGH&page=0&size=20	Listar hallazgos con filtros
GET	/api/v1/findings/{id}	Hallazgo individual
GET	/api/v1/findings/log/{logId}	Todos los hallazgos de un log

Dashboard

Método	Path	Descripción
GET	/api/v1/dashboard/summary	KPIs: totales por severidad + top 10 high-risk
GET	/api/v1/dashboard/findings/recent?hours=24	Hallazgos recientes (ventana configurable)

Reglas Personalizadas

Método	Path	Descripción
GET	/api/v1/rules	Todas las reglas
GET	/api/v1/rules/active	Solo reglas activas
POST	/api/v1/rules	Crear regla
PUT	/api/v1/rules/{id}	Actualizar regla
PATCH	/api/v1/rules/{id}/toggle	Activar/desactivar
DELETE	/api/v1/rules/{id}	Eliminar regla

---

Motor de Análisis — Flujo

POST /api/v1/analyze
  │
  ├─ 1. Persiste CommunicationLog en BD
  ├─ 2. Carga CustomRules activas
  ├─ 3. ¿app.llm.api-key configurado?
  │       ├─ SÍ → Virtual Thread → Feign → OpenAI Chat Completions
  │       │         Prompt: texto + normativas + reglas custom
  │       │         Response: JSON array de findings
  │       └─ NO → Keyword Fallback (GDPR/HIPAA/FINRA dictionaries + custom rules)
  ├─ 4. Persiste ComplianceFinding[] en BD
  ├─ 5. ¿HIGH o CRITICAL findings?
  │       └─ SÍ → AlertService.sendAlert() → log WARNING (+ email si configurado)
  └─ 6. Devuelve AnalysisResponse con findings y conteos

---

Configuración

application.yml — override defaults bajo app:

app:
  jwt:
    secret: "your-secret-min-32-chars"
    expiration: 86400000   # 24 horas en ms

  llm:
    base-url: "https://api.openai.com/v1"
    api-key: "sk-..."        # dejar vacío → modo keyword fallback
    model: "gpt-4o-mini"

  alerts:
    compliance-officer-email: "compliance@empresa.com"
    email-enabled: false     # true → usar SMTP (requiere spring-boot-starter-mail)

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/compliguard
    username: postgres
    password: secret
  jpa:
    hibernate:
      ddl-auto: update

---

Cómo Ejecutar (Dev — H2 en memoria)

cd solutions/2026-06-25-compliguard-ai

# Compilar
mvn clean compile

# Ejecutar (H2 sin configuración adicional)
mvn spring-boot:run

La aplicación arranca en http://localhost:8080.

Seed automático: Al primer arranque se crea el usuario admin / admin1234 y 4 reglas de ejemplo para FINRA, HIPAA y GDPR.

Flujo de prueba rápido

# 1. Login
TOKEN=$(curl -s -X POST http://localhost:8080/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin1234"}' | jq -r .token)

# 2. Analizar una comunicación (modo keyword fallback)
curl -X POST http://localhost:8080/api/v1/analyze \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "externalId": "EMAIL-001",
    "source": "EMAIL",
    "content": "Hey, I have a hot tip about XYZ Corp before the announcement. Buy now!",
    "regulations": ["FINRA", "GDPR"]
  }'

# 3. Dashboard
curl -H "Authorization: Bearer $TOKEN" \
  http://localhost:8080/api/v1/dashboard/summary

# 4. Listar hallazgos HIGH
curl -H "Authorization: Bearer $TOKEN" \
  "http://localhost:8080/api/v1/findings?riskLevel=HIGH"

Modo LLM (OpenAI)

# application.yml
app:
  llm:
    api-key: "sk-..."
    model: "gpt-4o-mini"

Con la API key configurada, el análisis delega en el LLM vía Virtual Thread. El fallback keyword se activa automáticamente si la llamada al LLM falla.

---

Análisis de Negocio

Dimensión	Evaluación
Problema	"Painkiller" — las multas por incumplimiento son millonarias (GDPR: hasta 4% del turnover global)
Mercado	FinTech SME + Health-tech — presupuestos de compliance asignados, decisores claros
Monetización	B2B SaaS por niveles: volumen de análisis/mes × número de seats
Stickiness	Datos históricos, reglas custom y alertas crean lock-in operativo
Defensibilidad	Reglas custom + historial de la empresa = dataset privado difícil de replicar
Riesgo principal	Dependencia de API LLM externa (mitigado por keyword fallback y posible fine-tuning propio)

---

Referencias

• AI for Regulatory Compliance — PMC Article
• GDPR Official Text
• HIPAA for Developers
• FINRA Rules
• Spring Boot 4.0 Reference
• jjwt 0.12.x API
• Spring Cloud OpenFeign

---

Análisis FinOps para CompliGuard AI

Estimación de Costos Operativos

1. Uso de LLM y Costos Asociados: Basado en un volumen inicial estimado de 15,000 comunicaciones analizadas por mes, con un promedio de 1175 tokens por análisis (1025 input, 150 output), el consumo mensual de tokens se estima en ~17.6 millones de tokens.

Utilizando gpt-4o de OpenAI (Input: $5.00/1M tokens, Output: $15.00/1M tokens): Costo de tokens de entrada: 15.375M tokens $5.00/1M = $76.88 Costo de tokens de salida: 2.25M tokens $15.00/1M = $33.75

• Costo total de LLM: ~$110/mes

2. Costos de Infraestructura Cloud (AWS Baseline): Para soportar la aplicación Spring Boot y la base de datos PostgreSQL, se estima la siguiente configuración:

• Servidor de Aplicación (EC2): t3.small (2 vCPU, 2 GiB RAM) con Linux y almacenamiento SSD general. Costo estimado: ~$15/mes.
• Base de Datos (RDS): t3.micro PostgreSQL (2 vCPU, 1 GiB RAM, 20GB SSD). Costo estimado: ~$18/mes.
• Otros (Transferencia de datos, monitoreo CloudWatch, snapshots): ~$7/mes.
• Costo total de infraestructura cloud: ~$40/mes

3. Costos Mensuales Totales:

• LLM (OpenAI gpt-4o): $110
• Infraestructura Cloud (AWS): $40
• Costo operativo total estimado: ~$150/mes

Estimación de Ingresos y Margen de Beneficio

1. Modelo de Monetización: CompliGuard AI operará bajo un modelo B2B SaaS por suscripción, basado en el volumen de datos analizados y el número de usuarios.

2. Precios y Clientes Iniciales: Asumiendo un precio promedio de $175/mes por cliente (considerando un plan de entrada para PYMEs) y un objetivo inicial de 6 clientes: Ingreso mensual estimado: 6 clientes $175/cliente = $1050/mes

3. Margen de Beneficio:

• Ingreso Mensual: $1050
• Costos Operativos Mensuales: $150
• Beneficio Bruto: $1050 - $150 = $900

Margen de Beneficio: ($900 / $1050) 100 = ~85%

Este margen es excepcionalmente saludable para una micro-startup, reflejando la eficiencia del modelo SaaS y el alto valor percibido de la solución para el cumplimiento normativo.

Estrategias de Optimización FinOps

Para mantener este margen y escalar de manera sostenible, CompliGuard AI debe implementar las siguientes optimizaciones:

1. Uso Inteligente de LLM (Tiered LLM Usage): Implementar una lógica que dirija las comunicaciones de bajo riesgo a modelos de LLM más económicos (ej. %%INLINE32%%) o incluso a modelos de código abierto autoalojados para un pre-filtrado. Solo las comunicaciones que requieran un análisis profundo o que presenten un alto riesgo se enviarían a %%INLINE33%%, reduciendo drásticamente los costos de tokens.
2. Caché de Respuestas LLM: Desarrollar un sistema de caché para almacenar las respuestas del LLM para fragmentos de texto o reglas de cumplimiento que se repitan con frecuencia. Esto evitaría enviar la misma solicitud a la API del LLM múltiples veces.
3. Optimización de Prompts: Realizar ingeniería de prompts para asegurar que sean lo más concisos y eficientes posible, minimizando el número de tokens de entrada sin comprometer la calidad y precisión del análisis.
4. Compromiso con Recursos Cloud (Reserved Instances/Savings Plans): Una vez que se establezca un patrón de uso predecible, adquirir instancias reservadas (Reserved Instances) o planes de ahorro (Savings Plans) en AWS para las instancias EC2 y RDS. Esto puede generar descuentos significativos (20-60%) en comparación con el modelo bajo demanda.
5. Procesamiento por Lotes y Horarios Off-Peak: Para comunicaciones no urgentes, considerar el procesamiento por lotes durante horas de menor demanda. Esto puede optimizar el uso de los recursos de cómputo y, potencialmente, aprovechar tarifas de LLM más bajas si los proveedores las ofrecen.
6. Políticas de Retención de Datos: Implementar y hacer cumplir estrictas políticas de retención de datos para purgar automáticamente los logs de comunicaciones y los hallazgos de cumplimiento que ya no son legalmente requeridos. Esto reducirá los costos de almacenamiento en la base de datos a largo plazo.