No panorama fintech de 2026, a adoção da Inteligência Artificial Generativa já não é uma novidade, mas sim um padrão operacional. No entanto, o verdadeiro desafio não reside na implementação de um chatbot, mas na integração fiável dos LLM (Large Language Models) nos processos de decisão críticos. Neste guia técnico, exploraremos o prompt engineering finanças com uma abordagem de engenharia, focando-nos num caso de uso específico e de alto risco: a extração e validação de dados para a análise de crédito à habitação.

Abordaremos o problema principal da IA no âmbito financeiro: a natureza probabilística dos modelos generativos contra a necessidade determinística dos cálculos bancários. Como veremos, a solução reside numa arquitetura híbrida que combina a flexibilidade semântica de modelos como o GPT-4 (ou sucessores) com a rigidez lógica das Expressões Regulares (Regex) e dos controlos programáticos.

O Paradoxo da Precisão: Porque é que os LLM erram nas contas

Qualquer pessoa que tenha trabalhado com IA generativa sabe que os modelos são excelentes a compreender a linguagem natural, mas medíocres na aritmética complexa ou no respeito rigoroso de formatos de output não padrão. Num contexto YMYL (Your Money Your Life), um erro no cálculo da taxa de esforço (relação prestação/rendimento) não é uma alucinação aceitável; é um risco de compliance e uma potencial perda económica.

O prompt engineering finanças não diz respeito apenas à escrita de frases elegantes para o modelo. Trata-se de projetar um sistema de Guardrails (barreiras de segurança) que obriguem o modelo a operar dentro de limites definidos. A abordagem que utilizaremos baseia-se em três pilares:

• Chain-of-Thought (CoT): Forçar o modelo a explicitar o raciocínio antes de fornecer o dado final.
• Structured Output (JSON): Obrigar o modelo a devolver dados estruturados para a ingestão via API.
• Regex Validation Layer: Uma camada de código Python que verifica se o output do LLM respeita os padrões formais (ex: IBAN, NIF, formatos de data).

Fase 1: Engenharia do Prompt para Documentos Não Estruturados

Imaginemos que temos de extrair dados de um recibo de vencimento ou de uma avaliação imobiliária digitalizada (OCR). O texto está sujo, desordenado e cheio de abreviaturas. Um prompt genérico falharia. Temos de construir um prompt estruturado.

A Técnica da “Persona” e da “Definição de Contexto”

O prompt deve definir claramente o papel do modelo. Não estamos a pedir um resumo, estamos a pedir uma extração de dados ETL (Extract, Transform, Load).

SYSTEM ROLE:
És um Analista de Crédito Sénior especializado em análise de crédito à habitação. A tua tarefa é extrair dados financeiros críticos de texto não estruturado proveniente de documentação OCR.

OBJETIVO:
Identificar e normalizar o Rendimento Líquido Mensal e as despesas recorrentes para o cálculo da taxa de esforço.

RESTRIÇÕES:
1. Não inventes dados. Se um dado estiver ausente, devolve "null".
2. Ignora os bónus pontuais, foca-te na remuneração ordinária.
3. O output DEVE ser exclusivamente em formato JSON válido.

Implementar a Chain-of-Thought (CoT)

Para aumentar a precisão, utilizamos a técnica Chain-of-Thought. Pedimos ao modelo para “raciocinar” num campo separado do JSON antes de extrair o valor. Isto reduz drasticamente as alucinações sobre os números.

Exemplo de estrutura do prompt de utilizador:

INPUT TEXT:
[Inserir aqui o texto OCR do recibo de vencimento...]

INSTRUÇÕES:
Analisa o texto passo a passo.
1. Identifica todas as rubricas positivas (salário base, subsídios).
2. Identifica as retenções fiscais e segurança social.
3. Exclui ajudas de custo ou bónus não recorrentes.
4. Calcula o líquido se não estiver explicitamente indicado, caso contrário extrai o "Líquido do mês".

OUTPUT FORMAT (JSON):
{
  "reasoning": "String de texto onde explicas o raciocínio lógico seguido para identificar o líquido.",
  "net_income_value": Float ou null,
  "currency": "EUR",
  "document_date": "YYYY-MM-DD"
}

Fase 2: Implementação Python e Validação Híbrida

O prompt engineering finanças é inútil sem um backend que o suporte. Aqui entra em jogo a abordagem híbrida. Não confiamos cegamente no JSON do LLM. Passamo-lo através de um validador baseado em Regex e Pydantic.

Código Python para a Integração API

Abaixo, um exemplo de como estruturar a chamada API (utilizando bibliotecas padrão como openai e pydantic para a validação dos tipos) e integrar o controlo Regex.

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

# Definição do esquema de dados esperado (Guardrail #1)
class FinancialData(BaseModel):
    reasoning: str
    net_income_value: float
    currency: str
    document_date: str

    # Validador Regex para a data (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 data inválido. Requerido YYYY-MM-DD')
        return v

    # Validador lógico para o rendimento (Guardrail #3)
    @validator('net_income_value')
    def realistic_income_check(cls, v):
        if v  50000:  # Limiares de segurança para alerta manual
            raise ValueError('Valor de rendimento fora dos parâmetros padrão (Anomaly Detection)')
        return v

def extract_financial_data(ocr_text):
    prompt = f"""
    Analisa o seguinte texto OCR bancário e extrai os dados solicitados.
    TEXT: {ocr_text}
    Devolve APENAS um objeto JSON.
    """

    try:
        response = openai.ChatCompletion.create(
            model="gpt-4-turbo", # Ou modelo equivalente 2026
            messages=[
                {"role": "system", "content": "És um extrator de dados financeiros rigoroso."},
                {"role": "user", "content": prompt}
            ],
            temperature=0.0 # Temperatura a 0 para máximo determinismo
        )

        raw_content = response.choices[0].message.content
        
        # Parsing e Validação
        data_dict = json.loads(raw_content)
        validated_data = FinancialData(**data_dict)
        
        return validated_data

    except json.JSONDecodeError:
        return "Erro: O LLM não produziu um JSON válido."
    except ValidationError as e:
        return f"Erro de Validação de Dados: {e}"
    except Exception as e:
        return f"Erro genérico: {e}"

# Exemplo de utilização
# result = extract_financial_data("Recibo de vencimento mês Janeiro... Líquido a pagar: 2.450,00 euros...")

Fase 3: Gestão de Alucinações e Loop de Correção

O que acontece se a validação falhar? Num sistema de produção avançado, implementamos um Self-Correction Loop. Se o Pydantic levantar uma exceção (ex: formato de data errado), o sistema pode enviar automaticamente um novo pedido ao LLM incluindo o erro recebido.

Exemplo de Prompt de Correção Automática:
“Geraste um JSON com um erro. O campo ‘document_date’ não respeitava o formato YYYY-MM-DD. Corrige o valor e devolve novamente o JSON.”

Considerações sobre Privacidade e Segurança (YMYL)

Quando se aplica o prompt engineering às finanças, a gestão de dados PII (Personally Identifiable Information) é crítica. Antes de enviar qualquer texto OCR para uma API pública (mesmo que enterprise), é boa prática aplicar uma técnica de Anonymization Pre-Processing.

Utilizando Regex locais (portanto, não IA), podem-se mascarar nomes, números de contribuinte e moradas, substituindo-os por tokens (ex: [NOME_CLIENTE_1]). O LLM analisará a estrutura financeira sem expor a identidade real do requerente do crédito, mantendo a conformidade com o RGPD.

Conclusões: O Futuro da Análise de Crédito à Habitação

A integração entre prompt engineering finanças, lógica de programação tradicional e validação Regex representa o único caminho viável para trazer a IA para os processos core dos bancos. Não se trata de substituir o analista humano, mas de lhe fornecer dados pré-validados e normalizados, reduzindo o tempo de data entry em 80% e permitindo-lhe concentrar-se na avaliação do risco de crédito.

A chave do sucesso não é um modelo mais inteligente, mas uma engenharia do prompt mais robusta e um sistema de controlo mais rígido.

Perguntas frequentes