O acesso ao Amazon Bedrock Claude na Índia fecha uma importante lacuna de residência de dados

O acesso ao Amazon Bedrock Claude na Índia agora abrange três modelos, após depender anteriormente de infraestrutura global que poderia processar solicitações fora do país. Em 29 de setembro, a AWS adicionou Claude Opus 5, Claude Sonnet 5 e Claude Haiku 4.5 a um perfil de inferência geográfica específico para a Índia.

A mudança dá aos desenvolvedores acesso a esses modelos a partir das Regiões da AWS em Mumbai e Hyderabad. O Bedrock pode encaminhar cada solicitação entre as duas Regiões, mas a AWS afirma que todo o processo de inferência permanece dentro da Índia.

Esse limite é a verdadeira notícia. O Claude já estava acessível a clientes indianos do Bedrock por meio de inferência global entre Regiões. A nova opção troca o pool global de capacidade por um pool doméstico menor, com uma garantia de processamento mais útil.

Microsoft, Google e outros provedores de nuvem também oferecem opções de implantação regional para cargas de trabalho de IA. Agora, a AWS está reunindo seu catálogo de modelos, sua infraestrutura de roteamento e sua presença de nuvem na Índia em um único pacote de aquisição. Para empresas regulamentadas, essa combinação importa mais do que outra comparação de benchmarks.

O acesso ao Amazon Bedrock Claude na Índia muda onde a inferência é executada

A AWS alterou a geografia de processamento permitida, e não apenas adicionou o Claude a outro menu do console.

O novo perfil aceita solicitações da Ásia-Pacífico Mumbai, identificada como ap-south-1, e da Ásia-Pacífico Hyderabad, identificada como ap-south-2. O Bedrock então envia cada solicitação para a capacidade disponível do modelo em qualquer uma das Regiões.

Esse processo é inferência geográfica entre Regiões. Ele reúne capacidade computacional entre Regiões aprovadas dentro de uma geografia definida, impedindo ao mesmo tempo que a inferência ultrapasse esse limite.

A AWS afirma que prompts e resultados gerados podem se mover entre Mumbai e Hyderabad durante o processamento. Eles não saem da Índia quando os clientes usam o perfil indiano. O perfil de inferência da Índia da empresa explica o roteamento e nomeia os três modelos Claude compatíveis.

Essa distinção é importante porque “disponível na Índia” pode descrever diversas arquiteturas. Um cliente pode chamar um endpoint localizado na Índia enquanto o modelo subjacente processa dados em outro lugar. Um endpoint regional, por si só, não estabelece uma garantia de inferência dentro do país.

O perfil geográfico é mais específico. Sua lista de destinos contém as duas Regiões indianas da AWS, para que o gerenciador de capacidade do Bedrock possa escolher Mumbai ou Hyderabad sem enviar a carga de trabalho ao exterior.

Os desenvolvedores selecionam esse comportamento por meio de um perfil de inferência com o prefixo da Índia, em vez de um identificador direto de modelo. Os exemplos da AWS usam identificadores como in.anthropic.claude-sonnet-5 e in.anthropic.claude-opus-5.

Esse prefixo não é um metadado decorativo. Ele instrui o Bedrock a invocar o modelo por meio da política de roteamento da Índia. Aplicações que continuarem usando um perfil global manterão o comportamento de roteamento global.

O lançamento oferece suporte a três formas de chamar o Claude. As equipes podem usar a API Messages da Anthropic por meio do endpoint Bedrock Runtime, ou usar as APIs InvokeModel e Converse da Amazon. A API Converse fornece uma estrutura de solicitação comum entre os modelos Bedrock compatíveis.

A AWS também expõe os perfis em seu playground no console. Isso permite que as equipes testem prompts e o comportamento dos modelos antes de alterar o código da aplicação, permissões, monitoramento ou tráfego de produção.

Claude Opus 5 é voltado às cargas de trabalho de raciocínio mais exigentes desta linha. Claude Sonnet 5 funciona como a opção de propósito geral, enquanto Claude Haiku 4.5 enfatiza uma inferência mais rápida e leve. Portanto, o lançamento cobre mais de um patamar de desempenho.

O anúncio não significa que todos os componentes de uma aplicação de IA permaneçam automaticamente na Índia. Uma equipe ainda pode enviar a saída do modelo para um banco de dados no exterior, serviço de logging, sistema de análise ou fluxo de trabalho de revisão humana.

Os clientes precisam examinar todo o caminho dos dados. O novo perfil restringe a inferência dos modelos do Bedrock, não todos os serviços conectados à aplicação.

A AWS afirma que os dados dos clientes não são armazenados na Região de destino durante a inferência entre Regiões. Eles permanecem armazenados na Região de origem, enquanto prompts e respostas podem ser processados em qualquer uma das duas Regiões indianas.

Essa separação entre processamento e armazenamento merece atenção. Uma solicitação originada em Mumbai pode ser processada em Hyderabad, mas seus registros persistentes de serviço permanecem vinculados a Mumbai na arquitetura descrita.

Os registros do CloudWatch e do CloudTrail também permanecem na Região de origem. O faturamento e o uso de cotas se vinculam a essa origem, mesmo quando a outra Região indiana fornece a capacidade do modelo.

O resultado prático é um pool doméstico de inferência em duas Regiões, com registros operacionais centralizados. Isso é materialmente diferente tanto da hospedagem em uma única Região quanto do roteamento global irrestrito.

Por que a inferência na Índia importa mais do que outro lançamento do Claude

O lançamento elimina uma objeção arquitetural que a qualidade do modelo, por si só, não conseguiria responder.

Bancos, seguradoras, organizações de saúde, fornecedores governamentais e grandes empregadores frequentemente classificam dados antes de aprovar uma carga de trabalho de IA. Suas análises podem abranger locais de processamento, subprocessadores, registros de auditoria, retenção, criptografia e controles de acesso.

Um modelo pode ter bom desempenho e ainda assim não passar nessa análise. Se os prompts puderem ser processados em uma Região estrangeira desconhecida, a implantação pode parar antes que um usuário de produção envie uma única solicitação.

O arcabouço de proteção de dados da Índia não cria uma regra universal que exija que todas as cargas de trabalho com dados pessoais permaneçam dentro do país. Regras setoriais, contratos, políticas internas e decisões de risco ainda podem impor limites mais restritos.

As regras de proteção de dados notificadas também tornam a governança uma preocupação operacional contínua. Os compradores precisam interpretar esses requisitos em conjunto com obrigações específicas de seus setores e suas próprias classificações de dados.

Isso torna a alegação da AWS útil, mas limitada. “Processado dentro da Índia” fornece às equipes de compliance um controle concreto de infraestrutura. Não certifica uma aplicação como compatível com todas as leis ou políticas aplicáveis.

Em um sistema de atendimento ao cliente, os prompts podem conter nomes, históricos de contas ou registros de reclamações. Um assistente de saúde pode receber notas clínicas. Um fluxo de trabalho jurídico pode enviar contratos contendo termos comerciais confidenciais.

Esses casos de uso não são exemplos hipotéticos de borda. Eles representam o material empresarial que torna os modelos avançados valiosos e o roteamento irrestrito difícil de aprovar.

O perfil Amazon Bedrock Claude India oferece aos arquitetos uma resposta mais clara sobre onde ocorre a inferência dos modelos. Também pode simplificar diagramas de fluxo de dados usados durante análises de privacidade e segurança.

Isso é especialmente relevante para geração aumentada por recuperação, ou RAG. O RAG fornece a um modelo documentos selecionados no momento da solicitação, para que ele possa responder usando conhecimento organizacional privado.

Uma empresa pode manter seu índice de documentos em Mumbai, mas anteriormente enviar trechos recuperados por meio de um perfil de inferência global. O banco de dados permanecia local, enquanto os trechos mais sensíveis poderiam cruzar fronteiras durante o processamento pelo modelo.

O perfil da Índia fecha essa lacuna específica quando a aplicação usa um modelo Claude compatível. Ele não elimina a necessidade de proteger o índice, a camada de recuperação, os logs da aplicação ou a interface do usuário.

Equipes que desenvolvem sistemas internos de pesquisa enfrentam uma questão semelhante. Uma ferramenta pode combinar notas de reuniões, registros de clientes e documentos técnicos antes de criar um resumo. É nesse ponto que uma base de conhecimento de IA bem governada precisa de recuperação útil e limites explícitos de processamento.

O momento também reflete uma estratégia mais ampla da AWS. O Bedrock passou a estar disponível em Hyderabad em fevereiro de 2025, adicionando uma segunda Região indiana capaz de oferecer suporte ao serviço.

Uma Região indiana pode atender a um rótulo geográfico, mas duas Regiões permitem roteamento doméstico entre Regiões. Agora, a AWS pode combinar processamento local com um pool de capacidade mais amplo e um destino alternativo durante picos de demanda.

Esse é o mecanismo por trás do anúncio. Os novos modelos Claude atraem atenção, mas a arquitetura de segunda Região torna a promessa de residência operacionalmente útil.

A AWS já havia permitido que clientes em Mumbai e Hyderabad acessassem modelos Claude anteriores por meio de inferência global entre Regiões. Essa abordagem melhorava o acesso à capacidade mundial, mas não mantinha o processamento dentro da Índia.

O lançamento de setembro introduz uma escolha real. Equipes sem restrições de localização podem preferir o roteamento global, enquanto equipes com exigências domésticas podem selecionar o perfil da Índia.

Isso transforma a residência em uma decisão de invocação, em vez de exigir uma plataforma de modelos separada. Uma empresa pode usar uma família de APIs e escolher diferentes perfis de inferência para cargas de trabalho distintas.

Essa flexibilidade também introduz trabalho de governança. Os desenvolvedores precisam impedir que aplicações restritas chamem acidentalmente perfis globais. Permissões, políticas de controle de serviço, revisão de código e verificações de implantação passam a fazer parte desse limite.

O roteamento geográfico é o mecanismo e a contrapartida

O perfil da Índia obtém um limite definido ao abrir mão do acesso ao pool mundial de capacidade do Bedrock.

A inferência entre Regiões existe principalmente para gerenciar capacidade. Cargas de trabalho de modelos grandes podem chegar em picos, e uma única Região pode nem sempre ter computação disponível suficiente para atender todas as solicitações de forma consistente.

Os perfis de inferência do Bedrock permitem que a AWS encaminhe chamadas para múltiplos destinos sem exigir que os clientes construam seu próprio gerenciador de tráfego. O cliente invoca um perfil, enquanto o serviço escolhe uma Região qualificada.

Com um perfil global, esse conjunto qualificado pode abranger Regiões comerciais compatíveis da AWS. Com a inferência geográfica, o conjunto permanece dentro de uma geografia nomeada.

A documentação de roteamento da AWS descreve os perfis de inferência como combinações de um modelo fundacional e Regiões de destino permitidas. Assim, o perfil define tanto o acesso ao modelo quanto o escopo de roteamento.

Para a Índia, os destinos permitidos são Mumbai e Hyderabad. Uma solicitação enviada em qualquer uma das Regiões pode usar capacidade na outra.

Esse design oferece mais resiliência do que vincular cada solicitação a uma única Região. Ele pode absorver demanda desigual entre os dois locais e reduzir a dependência de um único pool de capacidade.

No entanto, duas Regiões domésticas ainda oferecem menos opções de roteamento do que uma rede mundial. Os clientes que escolhem o perfil da Índia aceitam esse pool mais restrito para preservar o limite de processamento.

A AWS não promete que o roteamento geográfico eliminará limitação de solicitações, variação de latência ou limites de capacidade. As cotas de serviço continuam se aplicando, e as equipes de produção precisam testar seus próprios padrões de tráfego.

A contabilização de cotas ocorre na Região de origem. Esse detalhe afeta o planejamento de implantação porque uma aplicação não pode presumir que o roteamento para Hyderabad transfira o consumo de cotas para fora de Mumbai.

O monitoramento também permanece centralizado na origem. As métricas do CloudWatch e a atividade do CloudTrail aparecem ali, em vez de serem divididas de acordo com a Região que atendeu cada solicitação.

Isso pode simplificar as operações, mas também significa que esses logs não identificam necessariamente a localização de backend da forma que uma equipe de aplicação poderia esperar. Os compradores devem confirmar quais detalhes de auditoria seus controles exigem.

O caminho de rede é outra parte do argumento da AWS. A empresa afirma que a inferência entre Regiões usa sua rede privada com criptografia de ponta a ponta para dados em trânsito.

As orientações de segurança da AWS também alertam que as políticas de acesso devem considerar todas as Regiões incluídas em um perfil de inferência. Uma política restritiva pode bloquear involuntariamente um destino válido.

Isso cria um desafio de configuração. Um cliente quer permissões amplas o suficiente para ambas as Regiões indianas, mas restritas o bastante para impedir o processamento global ou regional não autorizado.

As políticas de controle de serviço podem impor restrições organizacionais. As políticas de Identity and Access Management podem limitar quais ações e perfis do Bedrock uma carga de trabalho pode invocar.

As equipes devem testar esses controles em ambas as Regiões de origem. Hyderabad é uma Região AWS de adesão opcional para contas, mas o comportamento de roteamento do Bedrock e os requisitos de políticas organizacionais nem sempre correspondem a uma simples premissa de ativado ou desativado.

A interface do modelo também afeta o esforço de migração. Aplicações que já usam Converse podem precisar apenas alterar o identificador do perfil, sujeito a permissões e ao comportamento específico do modelo.

Aplicações que chamam a API Messages da Anthropic podem direcionar o SDK ao endpoint Bedrock Runtime em uma Região indiana. Elas ainda precisam de autenticação, direitos de acesso e do identificador correto do modelo indiano.

InvokeModel oferece acesso de nível mais baixo ao formato de solicitação nativo de cada modelo. Isso pode preservar integrações existentes, embora as equipes continuem responsáveis por payloads específicos de cada versão e pelo tratamento das respostas.

Nenhuma dessas interfaces torna a substituição de modelos automática. Opus, Sonnet e Haiku podem diferir em latência, comportamento de saída, uso de ferramentas e adequação à carga de trabalho.

Uma migração responsável, portanto, testa mais do que a conectividade. As equipes devem avaliar a qualidade das respostas, o comportamento de recusa, a compatibilidade de prompts, a taxa de transferência, os logs e o tratamento de falhas com o perfil da Índia.

Elas também devem testar o que acontece quando a capacidade se torna limitada. Um perfil doméstico não pode escapar silenciosamente para uma Região global sem violar sua promessa central.

Essa restrição é o produto. Também é o risco para o qual os compradores precisam se preparar.

A AWS Está Competindo em Controle, Não Apenas em Escolha de Modelo

A principal disputa é entre capacidade global e processamento local aplicável, com a AWS tentando oferecer ambos por meio de perfis separados.

A concorrência em IA na nuvem costuma se concentrar em qual fornecedor lista primeiro o modelo mais recente. As compras empresariais são cada vez mais moldadas por uma pergunta diferente: onde cada solicitação realmente será executada?

A AWS está posicionando o Bedrock como uma camada de controle entre fornecedores de modelos. Os clientes podem usar serviços comuns de identidade, monitoramento, proteções e APIs enquanto selecionam modelos de diferentes fornecedores.

O lançamento do Claude na Índia reforça esse argumento. A Anthropic fornece os modelos, mas a AWS fornece o limite de roteamento doméstico, os endpoints regionais, as permissões, os logs e o gerenciamento de capacidade.

Esse pacote pressiona outros provedores de nuvem a tornar a disponibilidade de modelos e a geografia do processamento igualmente explícitas. Um nome de serviço regional é menos persuasivo quando suas regras de roteamento continuam difíceis de explicar.

A Microsoft documenta tipos de implantação regionais e mais amplos para seus modelos hospedados. Seu guia de implantação regional afirma que as implantações regionais padrão processam prompts e respostas na Região associada à implantação.

O Google Cloud também oferece controles regionais para serviços e modelos de IA generativa compatíveis. A disponibilidade pode variar por modelo, recurso, endpoint e modo de implantação em cada plataforma.

Essas diferenças tornam pouco confiáveis comparações simples entre provedores. Um modelo disponível por meio de um marketplace de nuvem não está necessariamente disponível com os mesmos controles geográficos, opções de taxa de transferência ou recursos de API.

A vantagem imediata da AWS é a clareza em torno desse perfil específico. Ela nomeia dois destinos, três modelos Claude e três abordagens de API compatíveis.

O lançamento também segue um padrão reconhecível. A AWS já havia introduzido roteamento do Claude específico por geografia para mercados como Japão e Austrália, onde Regiões emparelhadas oferecem pools de capacidade doméstica.

A Índia agora se encaixa nessa arquitetura. Mumbai e Hyderabad fornecem o par regional, enquanto o perfil in. oferece às aplicações um destino de roteamento específico.

A pressão competitiva vai além das hyperscalers. As APIs diretas de modelos também precisam explicar locais de processamento, retenção de dados e controles empresariais quando os clientes as comparam com ofertas gerenciadas de nuvem.

Alguns desenvolvedores ainda preferirão acesso direto por causa da disponibilidade mais rápida de recursos ou de relações mais simples com fornecedores. Outros valorizarão o Bedrock porque ele se integra aos seus sistemas existentes de identidade e monitoramento da AWS.

O anúncio não resolve essa escolha. Ele torna o processamento local um motivo mais forte para escolher a rota gerenciada para um subconjunto das cargas de trabalho indianas.

A AWS também compete com seu próprio perfil global. A opção global oferece um pool de capacidade mais amplo e pode ser atraente quando a residência de dados não é necessária.

Essa comparação interna é mais importante do que uma rivalidade fabricada entre AWS e Microsoft. A decisão central do comprador é se um limite indiano fixo justifica as limitações operacionais de uma geografia de roteamento menor.

Cargas de trabalho que contêm conteúdo público, dados de teste sintéticos ou prompts de baixo risco podem favorecer a capacidade global. Registros de clientes, documentos internos e materiais regulados podem justificar o perfil da Índia.

Uma organização madura pode usar ambos. O passo importante é atribuir deliberadamente cada carga de trabalho, em vez de deixar os desenvolvedores escolherem perfis de forma ad hoc.

É aqui que a governança de modelos se torna concreta. Uma política deve conectar a classificação de dados a um modelo, perfil, Região, configuração de logs e ajuste de retenção aprovados.

Sem esse mapeamento, uma opção local pode se tornar pouco mais do que uma caixa de seleção. O controle só funciona quando o tráfego de produção o invoca de forma consistente.

O Que a Alegação de Residência de Dados Não Garante

A inferência no país reduz um grande risco, mas não protege nem certifica a aplicação completa.

A AWS afirma que o Bedrock não armazena entradas ou saídas de modelos por padrão, sob sua abordagem de retenção zero de dados. O anúncio também observa uma exceção envolvendo conteúdo sinalizado por classificadores de segurança automatizados para modelos que exigem revisão humana.

Essa exceção exige leitura cuidadosa durante as compras. Equipes que lidam com dados altamente sensíveis devem verificar os termos aplicáveis ao modelo, as condições de revisão e a documentação de suporte antes da implantação.

Os clientes também devem distinguir entre retenção de entradas do modelo e logs da aplicação. O próprio código pode registrar prompts, saídas, documentos recuperados, resultados de ferramentas ou rastros de erro.

Ferramentas de observabilidade podem se tornar um armazenamento secundário de dados não intencional. Um prompt que permanece dentro da Índia durante a inferência ainda pode ser copiado para outro lugar por um exportador de logs.

O mesmo problema se aplica a ferramentas conectadas. Um agente pode chamar um serviço de software no exterior, enviar um e-mail, pesquisar um índice global ou gravar a saída em um banco de dados estrangeiro.

O perfil geográfico do Bedrock não restringe esses destinos. O proprietário da aplicação deve mapear e controlar cada chamada externa.

A residência de dados também difere da soberania de dados. Residência descreve onde as informações são armazenadas ou processadas. Soberania também diz respeito às leis, entidades e autoridades governamentais que podem afetar essas informações.

O perfil da AWS fornece um controle de localização de processamento. Ele não resolve de forma independente a jurisdição contratual, o acesso legal, a certificação setorial nem todas as questões de transferência transfronteiriça.

O roteamento doméstico tampouco garante baixa latência. O processamento de Mumbai a Hyderabad permanece dentro da Índia, mas as condições de rede, a carga do modelo, as contagens de tokens e o design da aplicação ainda moldam o tempo de resposta.

Também não garante capacidade ilimitada. O perfil pode usar dois pools em vez de um, mas ambos pertencem à mesma geografia doméstica.

Um aumento repentino de demanda ainda pode criar limitação de requisições. As equipes devem solicitar cotas adequadas, realizar testes de carga, usar políticas de repetição e projetar uma degradação controlada.

A disponibilidade dos modelos também muda ao longo do tempo. A AWS pode introduzir versões mais recentes do Claude, retirar versões antigas ou variar o suporte entre interfaces e perfis.

Os clientes devem consultar a documentação atual de disponibilidade de modelos antes de comprometer um sistema de produção. Um anúncio registra uma data, enquanto o catálogo de serviços continua evoluindo.

Há outra incerteza em torno da paridade de recursos. A inferência principal pode estar disponível por meio de um perfil antes que todos os recursos relacionados do Bedrock ofereçam suporte ao mesmo modelo e geografia.

O anúncio de setembro menciona especificamente Bedrock Guardrails e roteamento inteligente de prompts entre os recursos compatíveis. Equipes que usam agentes, inferência em lote, avaliação ou outros serviços devem verificar cada dependência separadamente.

Compradores regulados devem solicitar evidências em vez de depender de um rótulo de produto. Evidências úteis incluem diagramas de arquitetura, identificadores de perfil, definições de políticas, registros do CloudTrail, configurações de cotas e comportamento de falha testado.

Eles também devem estabelecer uma resposta para o uso acidental de um perfil global. Controles preventivos são melhores, mas procedimentos de detecção e incidente continuam necessários.

A visão cética, portanto, é direta. A AWS criou um componente de infraestrutura confiável, não um resultado de conformidade pronto para uso.

Essa distinção não deve diminuir o lançamento. Ela explica como as empresas podem usá-lo de forma responsável.

Três Sinais Mostrarão se a Inferência na Índia Importa

O próximo teste é verificar se os clientes tratam o perfil da Índia como infraestrutura de produção, e não como um anúncio de disponibilidade regional.

O primeiro sinal é a paridade de modelos e recursos. Os compradores devem observar se futuras versões do Claude chegam ao perfil da Índia próximas às suas datas de disponibilidade global.

Um longo atraso enfraqueceria a proposta para equipes que precisam tanto de processamento local quanto de recursos atuais do modelo. Lançamentos rápidos e recorrentes mostrariam que a Índia se tornou uma geografia de implantação de primeira classe.

A paridade de recursos também importa. Guardrails, avaliação, agentes, cargas de trabalho em lote, gerenciamento de prompts e observabilidade precisam funcionar em conjunto para grandes sistemas de produção.

O segundo sinal é o desempenho operacional entre Mumbai e Hyderabad. As empresas devem monitorar limitações de requisições, latência, aumentos de cotas e disponibilidade do serviço sob tráfego real.

Um desempenho consistente sustentaria a alegação da AWS de que o roteamento entre duas Regiões oferece escala útil dentro do país. Restrições persistentes de capacidade empurrariam cargas de trabalho menos sensíveis de volta para perfis globais.

Estudos de caso públicos de clientes acrescentariam evidências valiosas. Os exemplos mais fortes descreveriam classes reais de cargas de trabalho, controles de governança e volumes de produção sem expor dados confidenciais.

O terceiro sinal é a resposta competitiva. Microsoft, Google, provedores diretos de modelos e empresas indianas de infraestrutura têm motivos para reforçar seus compromissos com o processamento local.

Os compradores devem procurar documentação precisa, e não declarações amplas sobre disponibilidade regional. Divulgações úteis nomeiam as Regiões de processamento, os modos de roteamento, o comportamento de retenção, a cobertura de API e as ferramentas de aplicação.

Mais concorrência tornaria os controles de localização mais fáceis de comparar. Também poderia reduzir o intervalo entre o lançamento global de um modelo e sua disponibilidade dentro de uma fronteira de processamento indiana.

Para os desenvolvedores, a ação imediata é prática. Faça um inventário dos aplicativos que enviam dados privados ao Claude, identifique seus IDs de perfil atuais e rastreie todos os serviços conectados de armazenamento e registro.

Em seguida, teste o perfil da Índia com prompts representativos e concorrência realista. Compare qualidade, latência, limitação de requisições, observabilidade e comportamento em caso de falha com a rota global.

Para compradores corporativos, faça uma pergunta decisiva: o provedor consegue demonstrar todo o caminho da solicitação, incluindo recuperação, inferência, registros, ferramentas e armazenamento?

O acesso ao Claude India no Amazon Bedrock agora fornece uma resposta mais sólida para a etapa de inferência. As organizações que mais se beneficiarão serão aquelas que verificarem as etapas restantes com o mesmo cuidado.