En el panorama fintech de 2026, la adopción de la Inteligencia Artificial Generativa ya no es una novedad, sino un estándar operativo. Sin embargo, el verdadero desafío no reside en la implementación de un chatbot, sino en la integración fiable de los LLM (Large Language Models) en los procesos de toma de decisiones críticos. En esta guía técnica, exploraremos el prompt engineering en finanzas con un enfoque ingenieril, centrándonos en un caso de uso específico y de alto riesgo: la extracción y validación de datos para el estudio de hipotecas.

Abordaremos el problema principal de la IA en el ámbito financiero: la naturaleza probabilística de los modelos generativos frente a la necesidad determinista de los cálculos bancarios. Como veremos, la solución reside en una arquitectura híbrida que combina la flexibilidad semántica de modelos como GPT-4 (o sucesivos) con la rigidez lógica de las Expresiones Regulares (Regex) y de los controles programáticos.

La Paradoja de la Precisión: Por qué los LLM fallan en las cuentas

Cualquiera que haya trabajado con IA generativa sabe que los modelos son excelentes para comprender el lenguaje natural pero mediocres en la aritmética compleja o en el respeto riguroso de formatos de salida no estándar. En un contexto YMYL (Your Money Your Life), un error en el cálculo de la relación cuota/ingresos no es una alucinación aceptable; es un riesgo de cumplimiento y una pérdida económica potencial.

El prompt engineering en finanzas no trata solo de escribir frases elegantes para el modelo. Se trata de diseñar un sistema de Guardrails (barreras de seguridad) que obliguen al modelo a operar dentro de límites definidos. El enfoque que utilizaremos se basa en tres pilares:

• Chain-of-Thought (CoT): Forzar al modelo a explicitar el razonamiento antes de proporcionar el dato final.
• Structured Output (JSON): Obligar al modelo a devolver datos estructurados para la ingesta vía API.
• Regex Validation Layer: Una capa de código Python que verifica si la salida del LLM respeta los patrones formales (ej. IBAN, NIF, formatos de fecha).

Fase 1: Ingeniería del Prompt para Documentos No Estructurados

Imaginemos que tenemos que extraer datos de una nómina o de una tasación inmobiliaria escaneada (OCR). El texto está sucio, desordenado y lleno de abreviaturas. Un prompt genérico fallaría. Debemos construir un prompt estructurado.

La Técnica del "Persona" y del "Context Setting"

El prompt debe definir claramente el rol del modelo. No estamos pidiendo un resumen, estamos pidiendo una extracción de datos ETL (Extract, Transform, Load).

SYSTEM ROLE:
Eres un Senior Credit Analyst especializado en el estudio de hipotecas. Tu tarea es extraer datos financieros críticos de texto no estructurado proveniente de documentación OCR.

OBJETIVO:
Identificar y normalizar el Ingreso Neto Mensual y los gastos recurrentes para el cálculo de la relación cuota/ingresos.

VÍNCULOS:
1. No inventes datos. Si un dato está ausente, devuelve "null".
2. Ignora los bonus puntuales, céntrate en la retribución ordinaria.
3. La salida DEBE ser exclusivamente en formato JSON válido.

Implementar la Chain-of-Thought (CoT)

Para aumentar la precisión, utilizamos la técnica Chain-of-Thought. Pedimos al modelo que "razone" en un campo separado del JSON antes de extraer el valor. Esto reduce drásticamente las alucinaciones sobre los números.

Ejemplo de estructura del prompt de usuario:

INPUT TEXT:
[Insertar aquí el texto OCR de la nómina...]

INSTRUCCIONES:
Analiza el texto paso a paso.
1. Identifica todos los conceptos positivos (salario base, contingencias).
2. Identifica las retenciones fiscales y de seguridad social.
3. Excluye reembolsos de gastos o bonus no recurrentes.
4. Calcula el neto si no está explícitamente indicado, de lo contrario extrae el "Neto del mes".

OUTPUT FORMAT (JSON):
{
  "reasoning": "Cadena de texto donde explicas el razonamiento lógico seguido para identificar el neto.",
  "net_income_value": Float o null,
  "currency": "EUR",
  "document_date": "YYYY-MM-DD"
}

Fase 2: Implementación en Python y Validación Híbrida

El prompt engineering en finanzas es inútil sin un backend que lo soporte. Aquí entra en juego el enfoque híbrido. No confiamos ciegamente en el JSON del LLM. Lo pasamos a través de un validador basado en Regex y Pydantic.

Código Python para la Integración API

A continuación, un ejemplo de cómo estructurar la llamada API (utilizando librerías estándar como openai y pydantic para la validación de tipos) e integrar el control Regex.

import openai
import json
import re
from pydantic import BaseModel, ValidationError, validator
from typing import Optional

# Definición del esquema de datos esperado (Guardrail #1)
class FinancialData(BaseModel):
    reasoning: str
    net_income_value: float
    currency: str
    document_date: str

    # Validador Regex para la fecha (Guardrail #2)
    @validator('document_date')
    def date_format_check(cls, v):
        pattern = r'^d{4}-d{2}-d{2}$'
        if not re.match(pattern, v):
            raise ValueError('Formato de fecha no válido. Requerido YYYY-MM-DD')
        return v

    # Validador lógico para los ingresos (Guardrail #3)
    @validator('net_income_value')
    def realistic_income_check(cls, v):
        if v  50000:  # Umbrales de seguridad para alerta manual
            raise ValueError('Valor de ingresos fuera de los parámetros estándar (Anomaly Detection)')
        return v

def extract_financial_data(ocr_text):
    prompt = f"""
    Analiza el siguiente texto OCR bancario y extrae los datos solicitados.
    TEXT: {ocr_text}
    Devuelve SOLO un objeto JSON.
    """

    try:
        response = openai.ChatCompletion.create(
            model="gpt-4-turbo", # O modelo equivalente 2026
            messages=[
                {"role": "system", "content": "Eres un extractor de datos financieros riguroso."},
                {"role": "user", "content": prompt}
            ],
            temperature=0.0 # Temperatura a 0 para máximo determinismo
        )

        raw_content = response.choices[0].message.content
        
        # Parsing y Validación
        data_dict = json.loads(raw_content)
        validated_data = FinancialData(**data_dict)
        
        return validated_data

    except json.JSONDecodeError:
        return "Error: El LLM no ha producido un JSON válido."
    except ValidationError as e:
        return f"Error de Validación de Datos: {e}"
    except Exception as e:
        return f"Error genérico: {e}"

# Ejemplo de uso
# result = extract_financial_data("Nómina mes Enero... Neto a pagar: 2.450,00 euros...")

Fase 3: Gestión de Alucinaciones y Bucle de Corrección

¿Qué sucede si la validación falla? En un sistema de producción avanzado, implementamos un Self-Correction Loop. Si Pydantic lanza una excepción (ej. formato de fecha erróneo), el sistema puede enviar automáticamente una nueva solicitud al LLM incluyendo el error recibido.

Ejemplo de Prompt de Corrección Automática:
"Has generado un JSON con un error. El campo ‘document_date’ no respetaba el formato YYYY-MM-DD. Corrige el valor y devuelve nuevamente el JSON."

Consideraciones sobre Privacidad y Seguridad (YMYL)

Cuando se aplica el prompt engineering a las finanzas, la gestión de los datos PII (Personally Identifiable Information) es crítica. Antes de enviar cualquier texto OCR a una API pública (aunque sea enterprise), es una buena práctica aplicar una técnica de Anonymization Pre-Processing.

Utilizando Regex locales (por tanto, no IA), se pueden enmascarar nombres, NIF y direcciones sustituyéndolos con tokens (ej. [NOMBRE_CLIENTE_1]). El LLM analizará la estructura financiera sin exponer la identidad real del solicitante de la hipoteca, manteniendo la conformidad con el RGPD.

Conclusiones: El Futuro del Estudio de Hipotecas

La integración entre prompt engineering en finanzas, lógica de programación tradicional y validación Regex representa la única vía viable para llevar la IA a los procesos core de los bancos. No se trata de sustituir al analista humano, sino de proporcionarle datos pre-validados y normalizados, reduciendo el tiempo de data entry en un 80% y permitiéndole concentrarse en la evaluación del riesgo de crédito.

La clave del éxito no es un modelo más inteligente, sino una ingeniería del prompt más robusta y un sistema de control más rígido.

Preguntas frecuentes