Toda seguradora que integra corretoras, parceiros de distribuição, sistemas de resseguro ou canais digitais já depende de APIs, mesmo quando essa dependência não está claramente registrada no planejamento da diretoria.
Cada cotação online, consulta de sinistro por aplicativo, integração com parceiros ou compartilhamento previsto pelo Open Insurance passa por uma interface responsável por trocar dados em tempo real.
O problema é que essa dependência frequentemente cresce mais rápido que a governança sobre ela. Muitas operações possuem integrações construídas em momentos diferentes, por equipes distintas e sem um inventário centralizado. Cada uma pode se transformar em um ponto de acesso a dados de apólices, sinistros e informações pessoais dos segurados.
A responsabilidade pela segurança e pela continuidade da operação não desaparece quando o processamento ou o armazenamento de dados é terceirizado. O Manual de Orientações sobre Segurança Cibernética da Susep reforça que a gestão de terceiros deve integrar a estrutura de riscos e a política de segurança cibernética da supervisionada.
Este guia explica o que é a segurança de APIs no setor de seguros, onde as fragilidades costumam aparecer, quais exigências regulatórias devem ser consideradas e como avaliar se a estrutura atual pode ser mantida, precisa evoluir gradualmente ou exige uma arquitetura mais organizada.
Principais pontos
- A segurança de APIs depende de governança, controles técnicos e gestão contínua, não apenas de uma ferramenta de autenticação.
- APIs antigas, sem documentação ou responsável definido, ampliam o risco operacional e dificultam auditorias.
- A Circular Susep nº 638/2021 estabelece requisitos mínimos de segurança cibernética para as supervisionadas abrangidas.
- A Resolução Susep nº 90/2026 reforçou exigências relacionadas à documentação de serviços terceirizados de processamento e armazenamento de dados.
- As sociedades participantes do Open Insurance devem observar padrões técnicos específicos de segurança, certificação, criptografia e monitoramento.
- Nem toda seguradora precisa substituir seus sistemas: a decisão depende da maturidade da arquitetura, da criticidade dos dados e da capacidade de governança.
- O primeiro passo é identificar quais APIs existem, quais dados transportam, quem as utiliza e quem responde por elas.
⚠️ Ponto de atenção
Quando a integração depende de credenciais fixas nunca substituídas, acessos temporários que permanecem ativos ou documentação mantida apenas na memória de quem implementou a API, a exposição pode permanecer pouco visível no início.
Com o crescimento do volume de dados, do número de parceiros ou da complexidade operacional, essas limitações tendem a surgir na forma de incidentes, indisponibilidade, dificuldade de auditoria ou falhas no cumprimento de exigências regulatórias.
O objetivo não é criar medo em torno das APIs, mas garantir estrutura, registro e capacidade de resposta antes que uma limitação técnica afete a operação ou a relação com o segurado.
O que é segurança de APIs no setor de seguros?
Segurança de APIs no setor de seguros é a combinação de controles técnicos, operacionais e regulatórios que protege as interfaces usadas por seguradoras, corretoras, resseguradoras e parceiros para trocar dados de forma automatizada.
Essa estrutura inclui:
- Autenticação da aplicação ou do usuário.
- Autorização conforme perfil, finalidade e escopo.
- Criptografia dos dados em trânsito.
- Segmentação de informações sensíveis.
- Validação das requisições e respostas.
- Gestão de credenciais, certificados, tokens e segredos.
- Monitoramento de tráfego e comportamento.
- Registro de acessos e alterações.
- Identificação e correção de vulnerabilidades.
- Resposta a incidentes.
- Versionamento e desativação de APIs antigas.
- Governança sobre fornecedores e terceiros.
No setor de seguros, essas interfaces podem transportar CPF, histórico de sinistros, dados financeiros, valores segurados e, em determinados produtos, informações relacionadas à saúde. Também alimentam sistemas utilizados em subscrição, precificação, detecção de fraudes e automação de sinistros.
Uma falha em uma API, portanto, não se limita ao ambiente de tecnologia. Ela pode atingir dados protegidos pela LGPD, comprometer processos supervisionados pela Susep e reduzir a confiabilidade das decisões tomadas pela operação.
Por que a exposição de APIs cresceu nas seguradoras?
Três movimentos ajudam a explicar o aumento da dependência de APIs no mercado segurador.
Expansão do Open Insurance
A Resolução CNSP nº 415/2021 e a Circular Susep nº 635/2021 estruturaram a implementação do Sistema de Seguros Aberto.
Para as sociedades participantes e nos escopos aos quais a regulamentação se aplica, o compartilhamento de dados e serviços deve seguir especificações próprias. O Manual de Segurança do Open Insurance prevê, entre outros controles:
- Uso de APIs para acesso aos dados e serviços abrangidos.
- Segregação lógica de redes.
- Criptografia TLS 1.2 ou superior.
- Certificados digitais.
- Autenticação multifator em acessos administrativos remotos.
- Trilhas de auditoria.
- Monitoramento de erros, volumetria e padrões de requisição.
- Processos de análise de vulnerabilidades.
- Plano de resposta a incidentes.
Os controles técnicos do ecossistema também utilizam padrões como OAuth 2.0, OpenID Connect, FAPI e mTLS conforme o tipo de fluxo, o perfil de segurança e a finalidade da integração.
Veja como funciona o Open Insurance e o que ele exige das seguradoras sob a perspectiva regulatória e operacional.
Evolução do Sistema de Registro de Operações
O Sistema de Registro de Operações estabelece o registro estruturado de informações em sistemas homologados e administrados por entidades registradoras credenciadas pela Susep.
A obrigação não significa, necessariamente, que toda seguradora mantenha uma API direta com a autarquia. Na prática, porém, o envio estruturado e recorrente de informações pode exigir integrações entre sistemas internos e as infraestruturas utilizadas para o registro.
Quanto maior a fragmentação das bases, maior tende a ser o esforço necessário para validar, transformar e transmitir informações com consistência.
Crescimento do uso de inteligência artificial
Modelos de precificação, detecção de fraude, análise documental e automação de sinistros dependem de dados disponibilizados por diferentes sistemas.
A adoção de inteligência artificial não é uma obrigação regulatória. Entretanto, quando a empresa decide utilizar esses recursos, aumenta a importância de garantir que os dados consumidos pelas aplicações tenham origem conhecida, integridade preservada e acesso controlado.
Uma API vulnerável ou mal configurada pode comprometer não apenas a segurança das informações, mas também a confiabilidade dos modelos que dependem delas.
Esses movimentos possuem naturezas diferentes: Open Insurance e SRO criam exigências para as operações às quais se aplicam, enquanto a inteligência artificial representa uma decisão tecnológica e empresarial. Em comum, todos ampliam a necessidade de integrações rastreáveis e bem governadas.
Onde as fragilidades aparecem na operação?
Os problemas mais recorrentes costumam surgir em integrações criadas para atender a uma demanda pontual e que continuam funcionando sem revisão periódica.
Entre as situações mais comuns estão:
APIs que não constam em um inventário central.
Endpoints de versões antigas ainda disponíveis.
Ausência de responsável técnico e de negócio.
Credenciais compartilhadas entre equipes ou fornecedores.
Escopos de acesso mais amplos que a finalidade da integração.
Respostas que expõem dados além do necessário.
Configurações realizadas sob pressão de prazo.
Ausência de testes de segurança antes da publicação.
Falta de monitoramento de tráfego anômalo.
Contratos e avaliações de fornecedores difíceis de localizar.
Logs insuficientes para reconstruir um acesso.
Processos de resposta a incidentes que nunca foram testados.
Esses riscos se aproximam das categorias atuais do OWASP API Security Top 10, como falhas de autorização em nível de objeto, autenticação quebrada, configuração incorreta, gestão inadequada de inventário e consumo inseguro de APIs de terceiros.
Em uma estrutura madura, cada API nasce com responsável, finalidade, autenticação, escopo de dados, monitoramento e prazo de revisão definidos.
Em uma estrutura limitada, uma integração provisória pode se transformar em uma dependência permanente. Depois de algum tempo, ninguém sabe com precisão quais dados ela expõe, quem ainda possui acesso ou como seria desativada sem afetar outros processos.
Priorize as conexões que concentram maior esforço de manutenção, volume de dados sensíveis ou dependência de conhecimento individual. Esses pontos costumam indicar onde a arquitetura exige mais atenção.
O que costuma dar errado na prática?
| Erro recorrente | Por que acontece | Consequência possível | Como reduzir o risco |
|---|---|---|---|
| Integração sem inventário centralizado | Cada área ou parceiro cria APIs sob demanda, sem registro único | APIs antigas ou esquecidas permanecem disponíveis | Manter catálogo vivo, com responsável, finalidade, versão e escopo de dados |
| Autenticação inadequada ao risco | Escolha do mecanismo mais rápido sem avaliar finalidade e criticidade | Acesso indevido, baixa rastreabilidade ou dificuldade de revogação | Adotar o mecanismo compatível com o fluxo, como certificados, tokens, OAuth 2.0, OpenID Connect ou mTLS quando aplicável |
| Falha de autorização | A aplicação autentica o usuário, mas não valida quais objetos ou propriedades ele pode acessar | Exposição ou alteração de dados de outros segurados | Implementar autorização em nível de função, objeto e propriedade |
| Dados além do necessário | A API retorna o registro completo quando a operação exige apenas uma confirmação | Exposição desnecessária e conflito com o princípio da minimização | Limitar campos, escopos e respostas à finalidade da integração |
| Terceirização sem due diligence documentada | Fornecedor contratado sem processo formal de avaliação | Dificuldade de demonstrar controle e atender solicitações da Susep | Manter contratos, aditivos, avaliações de risco e evidências acessíveis |
| Ausência de limite de consumo | APIs não restringem volume ou frequência de chamadas | Indisponibilidade, custos inesperados ou abuso automatizado | Aplicar rate limiting, quotas, alertas e controles de capacidade |
| Falta de resposta a incidentes | A operação se concentra apenas em prevenção | Contenção lenta e comunicação desorganizada | Documentar e testar processos de identificação, contenção, recuperação e comunicação |
| Migração sem mapeamento prévio | Pressão para modernizar antes de compreender dependências | Ruptura de integrações críticas durante a transição | Mapear consumidores, dados, contratos e dependências antes da mudança |
| API antiga sem plano de desativação | Novas versões são lançadas sem retirar as anteriores | Endpoints desatualizados continuam expostos | Definir política de versionamento, comunicação e descontinuação |
O que a Susep exige sobre segurança de APIs?
A regulamentação brasileira não trata a segurança de APIs como uma disciplina isolada. As interfaces estão inseridas no arcabouço mais amplo de segurança cibernética, controles internos, gestão de riscos, terceirização e proteção de dados.
Circular Susep nº 638/2021
A Circular Susep nº 638/2021 estabelece requisitos mínimos de segurança cibernética para as supervisionadas abrangidas pela norma.
Entre os temas tratados estão:
- Política de segurança cibernética.
- Processos para identificar e reduzir vulnerabilidades.
- Detecção, resposta e recuperação de incidentes.
- Continuidade operacional.
- Terceirização de processamento e armazenamento de dados.
- Computação em nuvem.
- Documentação e governança.
A política e os controles devem ser compatíveis com o porte, a complexidade, o modelo de negócio e o perfil de risco da operação.
Resolução Susep nº 90/2026
Publicada no Diário Oficial da União em 20 de agosto de 2026, a Resolução Susep nº 90/2026 alterou o artigo 10 da Circular nº 638/2021.
A norma determina que, nos casos de terceirização de processamento ou armazenamento de dados, contratos, alterações e aditivos permaneçam acessíveis quando solicitados pela Susep. Essa obrigação também abrange informações e documentos necessários para avaliar:
- O serviço prestado.
- Os riscos envolvidos.
- A conformidade com a regulamentação aplicável.
Para a segurança de APIs, o impacto aparece quando fornecedores processam ou armazenam dados dentro desse escopo. Não basta saber que a integração funciona: a supervisionada precisa conseguir demonstrar como o serviço foi avaliado, quais riscos foram considerados e quais controles foram estabelecidos.
Manual de Orientações sobre Segurança Cibernética
Em julho de 2026, a Susep publicou um manual para orientar a implementação dos requisitos de segurança cibernética e reunir pontos de atenção identificados pela supervisão.
O documento diferencia:
Decorrem das normas aplicáveis.
São apresentadas como recomendações ou procedimentos desejáveis.
Essa distinção é importante. Nem toda recomendação possui o mesmo caráter de uma obrigação, mas pode indicar o nível de maturidade esperado em operações mais complexas ou expostas.
Open Insurance
As sociedades participantes do Open Insurance possuem uma camada adicional de requisitos técnicos.
Além das normas gerais de segurança cibernética, devem observar os manuais do ecossistema, que tratam de criptografia, certificados, autenticação, autorização, monitoramento, vulnerabilidades, trilhas de auditoria e resposta a incidentes.
Essas exigências se somam às obrigações da LGPD sobre finalidade, necessidade, segurança e proteção dos direitos dos titulares. Uma API que expõe mais dados do que o necessário pode representar, simultaneamente, uma falha técnica, uma fragilidade de governança e um risco de proteção de dados.
Se a resposta depende de buscas manuais em diferentes áreas, esse pode ser o primeiro ponto a estruturar para aumentar rastreabilidade, governança e capacidade de resposta.
Quais controles devem acompanhar o ciclo de vida de uma API?
A segurança não deve ser verificada apenas quando a API entra em produção. Ela precisa acompanhar todas as etapas da integração.
Planejamento e desenho
Antes do desenvolvimento, a operação deve definir:
- Finalidade da API.
- Dados necessários.
- Consumidores autorizados.
- Nível de criticidade.
- Responsável técnico.
- Responsável de negócio.
- Requisitos regulatórios.
- Política de retenção.
- Estratégia de descontinuação.
Desenvolvimento e testes
Durante o desenvolvimento, devem ser considerados:
- Validação de entrada e saída.
- Autorização em nível de função, objeto e propriedade.
- Proteção de segredos.
- Tratamento seguro de erros.
- Testes de vulnerabilidade.
- Revisão de código.
- Limites de consumo.
- Uso controlado de bibliotecas e componentes externos.
Publicação e operação
Depois da entrada em produção, tornam-se essenciais:
- Catálogo atualizado.
- Monitoramento de disponibilidade e comportamento.
- Alertas para acessos anômalos.
- Trilhas de auditoria.
- Rotação de credenciais.
- Aplicação de correções.
- Testes recorrentes.
- Revisão de permissões.
- Acompanhamento de fornecedores.
Versionamento e desativação
Toda API precisa ter uma estratégia para evoluir ou ser retirada de operação.
A empresa deve conhecer:
- Quais sistemas consomem cada versão.
- Quais dados ainda são transmitidos.
- Qual prazo foi comunicado aos consumidores.
- Como os acessos serão revogados.
- Quais registros precisam ser preservados.
- Como confirmar que o endpoint antigo deixou de responder.
Sem esse controle, versões antigas podem continuar acessíveis mesmo depois de perderem relevância operacional.
Critérios para avaliar a maturidade da arquitetura de APIs
Antes de decidir entre manter, evoluir ou reestruturar, avalie a operação a partir de critérios objetivos.
Inventário e visibilidade
Existe um catálogo único das APIs ativas, incluindo as criadas ou mantidas por parceiros?
Responsabilidade
Cada integração possui responsáveis técnicos e de negócio claramente definidos?
Autenticação e autorização
Os mecanismos adotados são compatíveis com o tipo de consumidor, a criticidade dos dados e os padrões regulatórios aplicáveis?
Minimização e segmentação
Cada API expõe apenas os dados necessários para sua finalidade?
Monitoramento contínuo
A equipe consegue identificar picos, erros recorrentes, tentativas de acesso indevido ou alterações no comportamento normal?
Gestão do ciclo de vida
Existem processos para versionar, revisar e desativar APIs antigas?
Resposta a incidentes
O processo está documentado, testado e é conhecido pelas equipes e fornecedores envolvidos?
Governança de terceiros
Contratos, aditivos, avaliações de risco e evidências de conformidade estão organizados e acessíveis?
Capacidade de auditoria
É possível reconstruir quem acessou determinado dado, em qual momento, por qual integração e com qual resultado?
Quando manter, evoluir ou reestruturar?
O volume de integrações é controlável, o inventário está atualizado, os responsáveis são conhecidos e os mecanismos de autenticação, autorização e monitoramento são compatíveis com o risco da operação.
Existem lacunas pontuais, como APIs sem padrão comum, documentação desatualizada ou monitoramento distribuído, mas a base tecnológica permite correções incrementais.
O número de integrações ultrapassou a capacidade de governança manual, os sistemas legados dificultam a adoção de padrões atuais ou a operação depende de múltiplos fornecedores sem um ponto central de controle.
Comparação entre alternativas
Como uma arquitetura orientada a APIs pode apoiar segurança e conformidade?
A criação de uma nova arquitetura não significa, necessariamente, substituir todos os sistemas existentes.
Em operações fragmentadas ou dependentes de legados, uma alternativa é estruturar uma camada de integração capaz de organizar a comunicação entre sistemas centrais, parceiros, canais digitais e serviços externos.
Essa camada pode apoiar:
- Inventário e governança das APIs.
- Padronização de autenticação e autorização.
- Centralização de monitoramento.
- Aplicação de regras de negócio.
- Transformação de formatos.
- Controle de versões.
- Gestão de acessos.
- Desacoplamento entre legado e novos canais.
- Evolução gradual da arquitetura.
Esse modelo é frequentemente chamado de Middle Office. Sua aplicação depende das características do legado, da criticidade das operações, dos requisitos regulatórios e do nível de maturidade da seguradora.
Como a Tecnologia Única atua nesse cenário?
A Tecnologia Única possui mais de duas décadas de experiência no desenvolvimento de soluções digitais para o mercado segurador brasileiro.
A atuação começa pela compreensão da operação: sistemas existentes, dependências, parceiros, dados, regras de negócio e objetivos de evolução. A partir desse diagnóstico, é possível avaliar se o melhor caminho envolve ajustes pontuais, uma camada de integração, modernização progressiva ou uma nova estrutura central.
A Proteo, solução da Tecnologia Única baseada na infraestrutura InsureMO, utiliza arquitetura orientada a APIs para apoiar a gestão de produtos, emissão, sinistros e integração com canais de distribuição.
Na Herval Seguradora, a combinação Proteo-InsureMO foi adotada como sistema central de uma nova operação digital. O projeto incluiu configuração de produtos, integração com canais de venda, emissão de apólices e gestão operacional.
Esse caso demonstra como uma arquitetura API-first pode sustentar uma operação digital desde a origem. Ele não representa uma implantação sobre sistemas legados; em cenários de coexistência, o desenho deve ser avaliado de acordo com as dependências e limitações da estrutura atual.
Conheça o caso Herval Seguradora, Proteo e InsureMO e veja também como funciona uma plataforma end to end para seguradoras.
Avalie a maturidade da sua segurança de APIs
Marque quantas afirmações representam a realidade atual da operação
Avalie os controles de inventário, responsabilidade, segurança, monitoramento e rastreabilidade das APIs.
0 de 8 critérios atendidos
A prioridade é construir visibilidade
Comece pelo inventário das APIs, pela identificação dos responsáveis e pelo mapeamento dos dados expostos. Antes de ampliar integrações ou adotar novas ferramentas, a operação precisa compreender o ambiente atual.
O diagnóstico revelou lacunas estruturais?
A Tecnologia Única pode apoiar a avaliação das integrações e a construção de um caminho proporcional à maturidade da operação.
Como estruturar o próximo passo?
Independentemente do estágio atual, alguns passos ajudam a reduzir incertezas antes de qualquer decisão maior:
Mapeie as integrações ativas, incluindo as mantidas por parceiros e fornecedores.
Registre a finalidade, o responsável e o escopo de dados de cada API.
Classifique as integrações conforme criticidade e sensibilidade das informações.
Valide autenticação e autorização de acordo com o tipo de fluxo.
Identifique credenciais antigas, compartilhadas ou sem processo de rotação.
Centralize logs e defina alertas para comportamentos anômalos.
Documente o processo de resposta a incidentes.
Revise contratos e evidências de avaliação de fornecedores.
Defina processos de versionamento e desativação.
Priorize as APIs que concentram maior exposição ou impacto operacional.
Quando o diagnóstico identifica limitações estruturais, faz sentido levar o cenário para uma conversa técnica antes de escolher ferramentas ou iniciar uma substituição ampla.
Conclusão
A segurança de APIs no setor de seguros deixou de ser uma preocupação restrita às equipes de desenvolvimento.
Ela está conectada à conformidade regulatória, à continuidade operacional, à proteção de dados, à confiabilidade de aplicações de inteligência artificial e à capacidade de integrar parceiros e canais digitais.
Manter APIs sem inventário, responsável, padrão de autenticação, monitoramento ou processo de desativação amplia a dificuldade de controlar a operação conforme ela cresce.
O caminho adequado depende da maturidade atual. Algumas seguradoras podem avançar com ajustes incrementais. Outras precisam estruturar uma camada de integração ou reavaliar componentes centrais da arquitetura.
O ponto de partida é sempre o mesmo: compreender o que existe, quais dados circulam, quais riscos estão concentrados e quais controles precisam evoluir.
A Tecnologia Única pode apoiar esse processo desde o diagnóstico até a estruturação de uma arquitetura integrada, rastreável e preparada para acompanhar as necessidades do negócio.
Perguntas frequentes sobre segurança de APIs no setor de seguros
O que muda com a Resolução Susep nº 90/2026?
A norma reforça que, nos casos de terceirização de processamento ou armazenamento de dados, contratos, alterações, aditivos e documentos necessários para avaliar o serviço, os riscos e a conformidade devem permanecer acessíveis quando solicitados pela Susep.
Isso pode abranger fornecedores responsáveis por integrações que processam ou armazenam dados dentro desse escopo.
Os manuais técnicos específicos são obrigatórios para as sociedades participantes e nos escopos abrangidos pelo Open Insurance.
As exigências gerais de segurança cibernética possuem alcance mais amplo conforme a regulamentação aplicável. Mesmo fora do Open Insurance, padrões equivalentes podem ser adotados como referência técnica, desde que sejam adequados ao contexto e ao risco da operação.
Segurança cibernética é o campo mais amplo, que envolve políticas, gestão de riscos, continuidade, proteção de dados, infraestrutura, pessoas e resposta a incidentes.
Segurança de APIs é uma disciplina dentro desse conjunto. Ela se concentra nas interfaces que conectam sistemas, com controles de autenticação, autorização, validação, criptografia, monitoramento e gestão do ciclo de vida.
A política de segurança cibernética deve ser compatível com o porte, a complexidade, o modelo de negócio e o perfil de risco da operação.
Isso permite proporcionalidade na implementação, mas não significa ausência de controles. Mesmo uma operação pequena precisa conhecer suas APIs, proteger credenciais, limitar acessos e responder a incidentes.
Os principais sinais são:
• Documentação desatualizada ou inexistente.
• Ausência de responsável.
• Credenciais compartilhadas.
• Versões antigas ainda disponíveis.
• Falta de monitoramento.
• Dificuldade para identificar os consumidores.
• Exposição de dados além da finalidade.
• Impossibilidade de desativação sem afetar vários processos.
Se a equipe não consegue responder rapidamente o que a API expõe, quem a utiliza e como o acesso é controlado, a integração merece prioridade de revisão.
Não. OAuth 2.0 é um framework de autorização e deve ser implementado dentro de uma arquitetura mais ampla.
A segurança também depende de autenticação, gestão de tokens, certificados, validação de escopos, autorização em nível de objeto, criptografia, monitoramento, testes e resposta a incidentes.
O protocolo adequado varia conforme o tipo de integração e o risco envolvido.
Não. Um gateway pode centralizar autenticação, políticas, limites de consumo, roteamento e monitoramento, mas não corrige sozinho falhas de autorização na aplicação, exposição excessiva de dados, processos frágeis ou ausência de governança.
A ferramenta precisa fazer parte de uma arquitetura acompanhada por processos, responsabilidades e controles consistentes.
Pode aumentar a dependência de APIs e o impacto de uma falha.
Modelos de precificação, fraude, atendimento ou automação de sinistros dependem da integridade dos dados recebidos. Se uma API é comprometida, o problema pode atingir tanto a proteção das informações quanto a confiabilidade das análises geradas pela IA.
Referências
[1] Susep. Circular Susep nº 638, de 27 de julho de 2021.
[2] Susep. Manual de Orientações sobre Segurança Cibernética.
[4] Susep. Documentos de referência do Open Insurance.
[5] Susep. Manual de Segurança do Open Insurance — versão 1.4.
[6] Susep. Circular Susep nº 710, de 24 de dezembro de 2024.
[7] OWASP. OWASP API Security Top 10 — 2023.
[8] Presidência da República. Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais.
EN 
PT 
ES 
FR 
IT 
DE