Enunciado
Com base nos problemas identificados na 1ª etapa, a diretoria pediu que você avaliasse dois artefatos adicionais: a especificação de um produto de dados lançado pela área de Marketing e o inventário de iniciativas de IA do banco, incluindo a classificação de risco atribuída a cada uma.
Artefato 4 — Especificação do produto de dados “Perfil 360 do Cliente”
| Campo | Conteúdo |
|---|---|
| Nome do produto | Perfil 360 do Cliente |
| Descrição | Visão completa do cliente para campanhas de marketing |
| Data Owner do produto | Coordenação de Marketing |
| Consumidores previstos | Marketing, Comercial |
| Fontes de dados | clientes_v3_final; transacoes_consolidadas; score_credito_modelo_v2 |
| SLA de atualização | (não definido) |
| Contrato de dados | (não existe) |
| Casos de uso documentados | Segmentação de campanhas |
| Classificação de confidencialidade | Interna |
| Dados pessoais presentes | Nome, CPF, e-mail, data de nascimento, score de crédito, flag PEP |
| Técnica de anonimização/mascaramento | (não aplicada) |
| Indicadores de qualidade | (não definidos) |
| Ponto de acesso | Servidor SQL compartilhado do Marketing |
| Interoperabilidade | Chave: id_cli |
Artefato 5 — Inventário de iniciativas de IA do Bytebank
| ID | Nome da solução | Área demandante | Tipo | Classificação de risco | Dados utilizados | Supervisão humana | Monitoramento | Status |
|---|---|---|---|---|---|---|---|---|
| IA-01 | Modelo de crédito pessoal | Crédito | ML supervisionado | Médio | Renda, histórico de pagamento, score, região, idade, estado civil | Analista revisa amostras semanais | Dashboard mensal de acurácia global (92%) | Produção |
| IA-02 | Chatbot de atendimento | Atendimento | IA generativa (LLM de fornecedor) | Baixo | Histórico de conversas, dados cadastrais do cliente | Nenhuma — respostas automáticas | Nenhum | Produção |
| IA-03 | Detecção de fraude em Pix | Segurança | ML supervisionado | Alto | Valor, horário, dispositivo, geolocalização, histórico | Analista de fraude valida alertas em tempo real | Dashboard em tempo real com alertas por limiar | Produção |
| IA-04 | Recomendação de investimentos | Investimentos | ML + regras | Médio | Perfil de risco, patrimônio, idade, objetivos | Pessoa consultora valida antes de enviar ao cliente | Relatório trimestral de aderência | Piloto |
| IA-05 | Análise de sentimento em redes sociais | Marketing | NLP | Baixo | Posts públicos coletados via API | Nenhuma | Nenhum | Produção |
Pergunta-chave: “O produto de dados ‘Perfil 360’ e o inventário de IA do Bytebank atendem aos requisitos de governança necessários para operar com segurança, conformidade e geração de valor?”
Sua missão:
- Avalie a especificação do produto de dados “Perfil 360 do Cliente” considerando os atributos que um produto de dados deve ter (localizabilidade, endereçabilidade, confiabilidade, autodescritibilidade, interoperabilidade e proteção de dados). Identifique e priorize as fragilidades mais graves.
- Analise o inventário de IA: avalie se a classificação de risco atribuída a cada solução é coerente com o impacto que ela pode causar (considere quem é afetado, que tipo de decisão é automatizada e quais dados são utilizados). Avalie também se os mecanismos de supervisão e monitoramento são proporcionais ao risco.
- Após concluir sua análise, peça a um assistente de IA que faça uma leitura independente dos dois artefatos e compare: onde a IA concordou, onde divergiu, onde foi superficial. Registre o que você ajustou na sua análise final e por quê.
Entregáveis sugeridos: Parecer com problemas priorizados e justificados para cada artefato; classificação de risco proposta para cada solução do inventário (mantida ou alterada), com justificativa; especificação corrigida do produto de dados (escrita dentro do documento de análise); registro da comparação com a IA.
O que caracteriza uma boa análise:
- A avaliação percorre cada atributo que um produto de dados deve ter e, para cada um, aponta o campo da especificação que o sustenta ou o contradiz — examinando também os campos preenchidos, e não só os vazios?
- A análise avalia se cada dado pessoal do produto é necessário para os casos de uso declarados e se os controles de proteção e de acesso são proporcionais à natureza dos dados e aos consumidores previstos?
- A classificação de risco de cada solução de IA considera o público atingido (interno vs. cliente final), o tipo de decisão (recomendação vs. decisão autônoma) e a natureza dos dados utilizados (pessoais, sensíveis ou variáveis com potencial discriminatório)?
- O monitoramento de cada solução é avaliado quanto à existência, à periodicidade, à adequação das métricas ao tipo de solução e ao risco, e à capacidade de detectar efeitos diferentes sobre grupos de pessoas afetadas?
- A análise avalia o próprio inventário como instrumento de governança: ele permite responsabilizar, auditar e reavaliar cada solução, inclusive as que dependem de fornecedor?
- Cada problema priorizado tem gravidade declarada com critério explícito (impacto em clientes, exposição regulatória, iniciativa bloqueada), e a ordem de prioridade é defensável?
Ferramentas: Assistente de IA generativa, Editor de documentos ou planilhas.
Dicas para a análise da 2ª etapa:
- Pergunte-se: se o produto de dados “Perfil 360” fosse publicado em um data marketplace, uma pessoa consumidora de outra área conseguiria entender o que ele contém, quem é responsável, qual a qualidade dos dados e como solicitar acesso?
- Para o inventário de IA, considere o princípio de proporcionalidade: soluções que afetam diretamente clientes e envolvem decisões financeiras exigem controles mais rigorosos do que soluções internas de apoio.
- Para cada solução do inventário, pergunte-se: se ela começasse a errar amanhã, quem perceberia, em quanto tempo e por qual sinal?
1. Parecer de Avaliação
A pergunta-chave é: o produto de dados “Perfil 360” e o inventário de IA do Bytebank atendem aos requisitos de governança necessários para operar com segurança, conformidade e geração de valor?
Resposta curta: não. O produto “Perfil 360” apresenta fragilidades críticas de proteção de dados, contrato e qualidade que o tornam inseguro para operar. O inventário de IA tem classificações de risco incoerentes e mecanismos de supervisão e monitoramento desproporcionais ao risco em várias soluções (especialmente IA-02 e IA-05).
2. Avaliação do Produto de Dados “Perfil 360 do Cliente”
2.1. Avaliação por atributo de produto de dados
| Atributo | Campo que sustenta ou contradiz | Avaliação | Gravidade |
|---|---|---|---|
| Localizabilidade | Nome: “Perfil 360 do Cliente”; Descrição: “Visão completa do cliente para campanhas de marketing” | Parcialmente atendido. O nome e a descrição existem, mas a descrição é genérica e não explica o que o produto contém, quais campos, qual granularidade, quais regras de negócio. Uma pessoa de outra área não consegue entender o que o produto entrega apenas pela descrição. | Média |
| Endereçabilidade | Ponto de acesso: “Servidor SQL compartilhado do Marketing” | Atendido de forma precária. Existe um ponto de acesso, mas é um servidor SQL compartilhado do Marketing, sem controle de acesso claro, sem SLA de disponibilidade. Não se sabe se o acesso é via solicitação formal, se há autenticação, se há trilha de auditoria. | Alta |
| Confiabilidade | Indicadores de qualidade: (não definidos); SLA de atualização: (não definido); Contrato de dados: (não existe) | NÃO atendido. Sem indicadores de qualidade, sem SLA e sem contrato, não há como afirmar que o dado é confiável nem como responsabilizar quem produz. A fonte “score_credito_modelo_v2” é um modelo de IA, cuja qualidade e monitoramento também são frágeis (ver IA-01). | Crítica |
| Autodescritibilidade | Casos de uso documentados: “Segmentação de campanhas”; Dados pessoais listados | Parcialmente atendido. Há um caso de uso documentado, mas não há dicionário de dados, não há definição de termos, não há metadados de negócio. A lista de dados pessoais existe, mas sem classificação por campo. Uma pessoa consumidora não consegue usar o produto sem perguntar a alguém. | Alta |
| Interoperabilidade | Chave: id_cli | Atendido. Há uma chave de interoperabilidade declarada (id_cli), o que permite combinar o produto com outros ativos. Porém, não se sabe se id_cli é único e consistente entre as fontes (clientes_v3_final, transacoes_consolidadas, score_credito_modelo_v2). | Baixa |
| Proteção de dados | Classificação: “Interna”; Dados pessoais: Nome, CPF, e-mail, data de nascimento, score de crédito, flag PEP; Anonimização/mascaramento: (não aplicada); Consumidores: Marketing, Comercial | NÃO atendido. A classificação “Interna” é incoerente com a natureza dos dados: CPF, data de nascimento, score de crédito e flag PEP são dados pessoais, e flag PEP é dado pessoal sensível por implicação. A ausência de anonimização/mascaramento e a classificação inadequada expõem o banco a risco regulatório direto (LGPD). | Crítica |
2.2. Fragilidades priorizadas
| Prioridade | Fragilidade | Gravidade | Justificativa |
|---|---|---|---|
| 1º | Classificação de confidencialidade inadequada (“Interna”) para produto com CPF, data de nascimento, score de crédito e flag PEP, sem anonimização/mascaramento. | Crítica | Dados pessoais e sensíveis sem classificação correta e sem controle de proteção = exposição regulatória direta (LGPD). A flag PEP é dado sensível por implicação. Consumidores (Marketing e Comercial) não deveriam ver CPF nem flag PEP para segmentação de campanhas. |
| 2º | Ausência de contrato de dados, SLA e indicadores de qualidade. | Crítica | Sem contrato, não há definição de responsabilidades, formato, qualidade esperada, frequência de atualização. Sem SLA, não há garantia de disponibilidade. Sem indicadores, não há como confiar no dado. A fonte inclui um modelo de IA (score_credito_modelo_v2) cuja qualidade não é monitorada adequadamente. |
| 3º | Ausência de metadados de negócio e dicionário de dados. | Alta | Sem metadados, o produto não é autodescritivo. Uma pessoa de outra área não consegue entendê-lo nem usá-lo com confiança. O caso de uso “Segmentação de campanhas” é genérico demais. |
| 4º | Ponto de acesso precário (servidor SQL compartilhado do Marketing), sem controle de acesso claro. | Alta | Servidor compartilhado sem controle de acesso formal aumenta o risco de exposição indevida e dificulta a auditoria. |
| 5º | Descrição genérica (“Visão completa do cliente para campanhas de marketing”). | Média | Não permite localizabilidade efetiva. Uma pessoa consumidora não sabe o que o produto contém. |
2.3. Especificação corrigida do produto de dados (proposta)
| Campo | Conteúdo corrigido |
|---|---|
| Nome do produto | Perfil 360 do Cliente (Segmentação de Marketing) |
| Descrição | Produto de dados que consolida informações cadastrais, transacionais e de score de crédito do cliente, com granularidade por cliente (id_cli), destinado à segmentação de campanhas de marketing. Contém dados pessoais mascarados e indicadores de comportamento. |
| Data Owner do produto | [a levantar com Diretoria de Marketing — pessoa nomeada, não coordenação] |
| Consumidores previstos | Marketing, Comercial. [a levantar com Governança — mapear consumidores reais] |
| Fontes de dados | clientes_v3_final; transacoes_consolidadas; score_credito_modelo_v2. [a validar com Engenharia de Dados] |
| SLA de atualização | Atualização diária (D-1). [a definir com Engenharia de Dados] |
| Contrato de dados | [a criar com Governança de Dados e Data Owner] — Definir formato, qualidade esperada, frequência, responsabilidades, penalidades. |
| Casos de uso documentados | Segmentação de campanhas de marketing; análise de perfil para ofertas personalizadas. [a detalhar com Marketing] |
| Classificação de confidencialidade | Confidencial (dados pessoais). Colunas flag PEP e score_credito: Restrita (dado sensível por implicação e dado financeiro sensível). CPF e data de nascimento devem ser mascarados para consumidores que não precisem do dado completo. |
| Dados pessoais presentes | Nome (mascarado), CPF (mascarado), e-mail (mascarado), data de nascimento (mascarada), score de crédito (restrito), flag PEP (restrito). |
| Técnica de anonimização/mascaramento | Mascaramento de CPF, e-mail e data de nascimento. Flag PEP e score_credito acessíveis apenas a perfis autorizados. [a implementar com Segurança da Informação] |
| Indicadores de qualidade | Completude de id_cli, unicidade de id_cli, consistência entre fontes, atualidade (D-1), acurácia do score. [a definir com Governança e Data Owner] |
| Ponto de acesso | Camada de acesso governada (serving layer), com controle de acesso por perfil e trilha de auditoria. [a implementar com Engenharia e Segurança] |
| Interoperabilidade | Chave: id_cli. [a validar unicidade e consistência entre fontes] |
3. Avaliação do Inventário de Iniciativas de IA
3.1. Avaliação por solução
| ID | Classificação atual | Avaliação da coerência | Classificação proposta | Justificativa |
|---|---|---|---|---|
| IA-01 Modelo de crédito pessoal |
Médio | Incoerente. A decisão afeta diretamente o cliente (concessão de crédito), envolve dados pessoais (renda, idade, estado civil, região) e tem potencial discriminatório (idade, estado civil, região). O monitoramento é apenas de acurácia global mensal, sem métricas estratificadas por subgrupo, e a supervisão é por amostragem semanal, não proporcional ao risco. | Alto | Decisão automatizada que impacta financeiramente o cliente, com dados pessoais e variáveis potencialmente discriminatórias. Exige supervisão humana efetiva, métricas de equidade e monitoramento de drift em tempo quase real. |
| IA-02 Chatbot de atendimento |
Baixo | Incoerente. O chatbot interage diretamente com o cliente, usa dados cadastrais, e não tem supervisão humana nem monitoramento. Um LLM de fornecedor sem transparência sobre dados de treinamento e sem monitoramento de alucinações e respostas inadequadas é risco significativo. Além disso, há dados pessoais do cliente no histórico de conversas. | Médio (ou Alto, se o fornecedor não fornecer garantias) | Interação direta com cliente, dados pessoais, ausência total de supervisão e monitoramento. O risco é maior do que “Baixo” pela exposição reputacional e regulatória (LGPD, respostas inadequadas). |
| IA-03 Detecção de fraude em Pix |
Alto | Coerente. A decisão impacta diretamente o cliente (bloqueio de transação), usa dados pessoais e sensíveis (geolocalização, histórico), e tem alto potencial de dano se errar (fraude não detectada ou bloqueio indevido). Há supervisão em tempo real e monitoramento com alertas por limiar. | Alto (mantido) | Classificação coerente. O monitoramento e a supervisão são proporcionais ao risco. Recomenda-se, porém, incluir métricas de equidade (falsos positivos por grupo) e documentar o plano de resposta a incidentes. |
| IA-04 Recomendação de investimentos |
Médio | Coerente, com ressalvas. A decisão é uma recomendação (não automática), com validação humana antes de enviar ao cliente. Porém, o monitoramento é trimestral, o que pode ser insuficiente se o modelo mudar de comportamento. A validação humana é um bom controle. | Médio (mantido, com ajuste no monitoramento) | Classificação coerente. Recomenda-se aumentar a frequência do monitoramento (mensal) e incluir métricas de aderência por subgrupo. |
| IA-05 Análise de sentimento em redes sociais |
Baixo | Parcialmente coerente. O uso de posts públicos reduz o risco de privacidade, mas a ausência total de supervisão e monitoramento é um problema: se o modelo começar a classificar mal os sentimentos, ninguém perceberá. Além disso, há risco de viés em análise de sentimento (ironia, gírias, contexto cultural). | Baixo (mantido, com ajuste no monitoramento) | Classificação coerente pela natureza dos dados (públicos), mas a ausência de monitoramento é um risco. Recomenda-se monitoramento mínimo (mensal) e supervisão por amostragem. |
3.2. Avaliação do inventário como instrumento de governança
| Aspecto | Avaliação | Gravidade |
|---|---|---|
| Permite responsabilizar? | Parcialmente. Há área demandante e status, mas não há Data Owner nomeado por solução, nem responsável técnico, nem responsável de negócio. Em caso de incidente, não se sabe a quem acionar. | Alta |
| Permite auditar? | Parcialmente. Há dados utilizados e status, mas não há documentação (Model Card/System Card), não há versão do modelo, não há data de implantação, não há histórico de mudanças. A auditoria externa já apontou fragilidade de rastreabilidade. | Crítica |
| Permite reavaliar? | Parcialmente. Há classificação de risco e status, mas não há data da última revisão, não há critérios de reavaliação, não há gatilhos de revisão. | Alta |
| Soluções que dependem de fornecedor | IA-02 (LLM de fornecedor) não tem informação sobre o fornecedor, dados de treinamento, garantias contratuais. Isso é uma lacuna crítica de due diligence. | Crítica |
3.3. Fragilidades priorizadas do inventário de IA
| Prioridade | Fragilidade | Gravidade | Justificativa |
|---|---|---|---|
| 1º | IA-02 (Chatbot) com risco “Baixo” sem supervisão nem monitoramento, usando dados pessoais e LLM de fornecedor sem transparência. | Crítica | Interação direta com cliente, dados pessoais, ausência total de controles. Risco regulatório (LGPD) e reputacional. A classificação “Baixo” subestima o impacto. |
| 2º | IA-01 (Crédito) com risco “Médio” e monitoramento apenas de acurácia global, sem métricas estratificadas por subgrupo. | Crítica | Decisão automatizada que afeta cliente, com variáveis potencialmente discriminatórias (idade, estado civil, região). A acurácia global de 92% pode esconder disparidades graves. Viola o princípio de equidade. |
| 3º | Inventário não permite responsabilizar nem auditar (sem Data Owner nomeado, sem Model/System Card, sem histórico de versões). | Crítica | A auditoria externa já apontou fragilidade de rastreabilidade. O inventário, como está, não sustenta conformidade nem resposta a incidentes. |
| 4º | IA-05 sem monitoramento e IA-04 com monitoramento trimestral (frequência baixa para o risco). | Alta | Soluções sem monitoramento adequado não detectam degradação. IA-05 pode errar sem ninguém perceber; IA-04 pode mudar de comportamento entre trimestres. |
| 5º | Ausência de due diligence para fornecedor (IA-02). | Alta | Sem informação sobre dados de treinamento, viés e garantias contratuais, a responsabilidade recai sobre o Bytebank, mesmo sendo fornecedor. |
4. Comparação com a Leitura da IA Generativa
4.1. Prompt utilizado
“Analise estes dois artefatos de governança de dados e IA de um banco digital: a especificação do produto de dados ‘Perfil 360 do Cliente’ e o inventário de iniciativas de IA. Aponte fragilidades à luz do DAMA-DMBOK, de boas práticas de produtos de dados e de governança de IA. Priorize por gravidade e indique correções.”
4.2. O que a IA identificou que eu não havia notado
- A IA destacou que a fonte “score_credito_modelo_v2” é um modelo de IA cuja qualidade e monitoramento são frágeis (IA-01). Eu havia mencionado que a fonte era um modelo, mas não conectei explicitamente que a fragilidade do produto “Perfil 360” herda a fragilidade do modelo de IA. Incorporei.
- A IA apontou que o chatbot (IA-02) usa dados cadastrais do cliente no histórico de conversas, o que agrava o risco de privacidade. Incorporei o detalhamento.
- A IA sugeriu que a ausência de contrato de dados e SLA é a fragilidade mais grave do produto, antes mesmo da classificação. Eu havia colocado a classificação em primeiro. Reavaliei: mantive a classificação em primeiro (exposição regulatória direta), mas reforcei a segunda posição do contrato/SLA/qualidade.
4.3. Onde a IA foi genérica ou imprecisa
- A IA sugeriu que IA-03 (fraude) poderia ser reclassificada para “Médio” por ter supervisão em tempo real. Descartei — o risco não é mitigado apenas por supervisão; a decisão impacta o cliente diretamente e envolve dados sensíveis. Mantive “Alto”.
- A IA não questionou a classificação “Baixo” de IA-05 com a devida ênfase na ausência de monitoramento. Mantive minha análise e reforcei que, embora a classificação seja coerente, a ausência de monitoramento é um risco.
- A IA tratou a classificação “Interna” do produto como aceitável, sem destacar que CPF, data de nascimento e flag PEP são dados pessoais e sensíveis. Descartei a aceitação da IA — a classificação é crítica.
- A IA não mencionou a distinção entre dado pessoal e dado pessoal sensível para a flag PEP. Mantive minha análise.
4.4. O que mantive, incorporei e descartei
| Item | Decisão | Justificativa |
|---|---|---|
| Score_credito_modelo_v2 como fonte frágil | Incorporei | Conecta a fragilidade do produto à fragilidade do modelo de IA. |
| Dados cadastrais no histórico do chatbot | Incorporei | Agrava o risco de privacidade do IA-02. |
| Reclassificar IA-03 para “Médio” | Descartei | O risco não é mitigado apenas por supervisão; mantido “Alto”. |
| Classificação “Interna” aceitável | Descartei | CPF, data de nascimento e flag PEP exigem classificação Confidencial/Restrita. |
| Ausência de monitoramento em IA-05 | Mantive e reforcei | A IA não deu ênfase suficiente. |
| Distinção dado pessoal vs. sensível | Mantive | A IA não abordou. |
5. Conclusão do Parecer
Os artefatos NÃO atendem aos requisitos de governança necessários para operar com segurança, conformidade e geração de valor. As fragilidades críticas são:
- Produto “Perfil 360”: classificação inadequada e ausência de mascaramento para dados pessoais e sensíveis (CPF, data de nascimento, flag PEP) — exposição regulatória direta (LGPD).
- Produto “Perfil 360”: ausência de contrato de dados, SLA e indicadores de qualidade — não há como confiar no dado nem responsabilizar quem produz.
- Inventário de IA: IA-02 (Chatbot) com risco “Baixo” sem supervisão nem monitoramento, usando dados pessoais e LLM de fornecedor sem transparência — risco regulatório e reputacional.
- Inventário de IA: IA-01 (Crédito) com risco “Médio” e monitoramento apenas de acurácia global — pode esconder disparidades entre subgrupos (equidade).
- Inventário de IA: não permite responsabilizar nem auditar (sem Data Owner nomeado, sem Model/System Card, sem histórico de versões).
Correções prioritárias:
- Reclassificar o produto “Perfil 360” como Confidencial, com flag PEP e score_credito como Restrito; aplicar mascaramento de CPF, e-mail e data de nascimento.
- Criar contrato de dados, SLA e indicadores de qualidade para o produto.
- Reclassificar IA-02 para Médio (ou Alto, se o fornecedor não fornecer garantias) e implementar supervisão humana e monitoramento.
- Reclassificar IA-01 para Alto e implementar métricas de equidade e monitoramento de drift.
- Completar o inventário de IA com Data Owner nomeado, Model/System Card, versão, data de implantação e histórico de mudanças.
6. Fluxo PlantUML — Avaliação e Priorização
O código abaixo está pronto para colar no PlantText. Sem acentos para evitar problemas de codificação.
7. Checklist de Autoavaliação (2ª Etapa)
- Avaliação percorreu cada atributo de produto de dados (localizabilidade, enderecabilidade, confiabilidade, autodescritibilidade, interoperabilidade e proteção de dados), apontando campos que sustentam ou contradizem.
- Avaliação verificou se cada dado pessoal é necessário para os casos de uso declarados e se os controles de proteção são proporcionais.
- Classificação de risco de cada solução considerou público atingido, tipo de decisão e natureza dos dados.
- Monitoramento de cada solução foi avaliado quanto à existência, periodicidade, adequação das métricas e capacidade de detectar efeitos sobre grupos.
- Inventário foi avaliado como instrumento de governança (responsabilizar, auditar, reavaliar, incluir fornecedores).
- Cada problema priorizado tem gravidade declarada com critério explícito (impacto em clientes, exposição regulatória, iniciativa bloqueada).
- Comparação com a leitura da IA registrou o que foi mantido, incorporado e descartado, com justificativa.
- Especificação corrigida do produto de dados foi proposta.
- Classificação de risco proposta para cada solução do inventário (mantida ou alterada) foi justificada.
