3. Fundamentos essenciais

1. DevOps
Integra desenvolvimento e operações para acelerar entregas, reduzir silos e criar ciclos contínuos de: 
•	publicação, 
•	verificação, 
•	feedback,
•	implantação.

2. DevSecOps
•	Incorpora segurança desde o início do ciclo. 
•	iA segurança deixa de ser uma etapa final e passa a ser requisito verificável em cada alteração.

3. Infrastructure as Code
Descreve recursos de infraestrutura por arquivos declarativos ou programáticos, permitindo:
•	versionamento, 
•	revisão, 
•	reprodução,
•	auditoria.

4. GitOps
Usa o repositório Git como fonte única da verdade para o estado desejado da infraestrutura e 
da aplicação.

5. Pipeline
Sequência automatizada de etapas para validar:
•	código, 
•	infraestrutura, 
•	políticas, 
•	segurança,
•	implantação.

6. Policy as Code
Códigos executáveis, como políticas Rego avaliadas pelo OPA, são criados a partir de :
•	regras de segurança, 
•	conformidade,
•	governança.

4. Analogia médica ampliada

5. Arquitetura segura para medicina assistida por IA

Uma arquitetura segura para IA médica deve combinar controles:
•	preventivos, 
•	detectivos,
•	responsivos.

O objetivo não é apenas colocar um modelo em produção, mas manter uma linha de evidência permanente sobre:
•	dados, 
•	infraestrutura, 
•	modelo, 
•	versão, 
•	acesso, 
•	decisão, 
•	erro,
•	correção.

1.	Identidade e acesso: 
* menor privilégio, 
* autenticação forte, 
* contas de serviço específicas, 
* ausência de credenciais estáticas,
* segregação por ambiente.

2.	Dados clínicos: 
* criptografia em repouso e em trânsito, 
* classificação de sensibilidade, 
* retenção controlada, 
* anonimização ou pseudonimização quando aplicável.

3.	Infraestrutura: 
* redes segmentadas, 
* recursos privados por padrão, 
* logs imutáveis, 
* backup, 
* versionamento,
* rastreabilidade do estado.

4.	Modelo de IA: 
* versionamento de artefatos, 
* validação de integridade, 
* monitoramento de drift, 
* trilha de inferências,
* avaliação pós-implantação.

5.	Pipeline: 
* revisão por pares, 
* testes, 
* scanning, 
* validação IaC, 
* policy as code,
* aprovação formal antes do deploy.

6.	Auditoria: 
* registro de quem alterou, 
* qual mudança foi aprovada, 
* qual política foi avaliada,
* qual evidência sustenta a implantação.

6. Modelo de ameaça clínico-computacional

Em ambientes de saúde, a ameaça não se limita a indisponibilidade ou vazamento. 

A infraestrutura também pode alterar indiretamente a qualidade da decisão clínica por meio de: 
•	atrasar inferências, 
•	expor exames, 
•	permitir alteração de modelos, 
•	modificar entradas de dados, 
•	quebrar integrações,
•	tornar impossível reconstruir uma cadeia de eventos adversos.

1.	Confidencialidade: 
* exposição de dados clínicos, 
* imagens, 
* laudos, 
* logs de inferência,
* chaves de acesso.

2.	Integridade: 
* alteração de infraestrutura, 
* dados de entrada, 
* artefatos de modelo,
* parâmetros de execução.

3.	Disponibilidade: 
* indisponibilidade de serviços de inferência, 
* APIs clínicas, 
* bancos de dados,
* trilas de integração.

4.	Rastreabilidade: 
    Ausência de logs suficientes para reconstruir:
* uma decisão,
* um incidente, 
* uma alteração.

5.	Segurança clínica: 
    Impacto direto ou indireto na decisão assistencial, com possibilidade de:
* atraso, 
* erro, 
* falso positivo, 
* falso negativo,
* conduta inadequada.

7. Cenário vulnerável 1: repositório de imagens médicas exposto na nuvem

1. Descrição

Um serviço de radiologia utiliza um modelo de IA para priorizar tomografias com suspeita de hemorragia
intracraniana. 

As imagens DICOM e logs de inferência são armazenados em um bucket de nuvem criado manualmente. 

Durante uma expansão emergencial, o bucket é configurado:
•	sem bloqueio de acesso público, 
•	sem criptografia obrigatória,
•	sem versionamento.

2. Vulnerabilidades principais
•	Bucket com risco de leitura pública ou política permissiva.
•	Dados sensíveis sem criptografia robusta em repouso.
•	Ausência de versionamento e trilha de auditoria adequada.
•	Criação manual sem revisão e sem política automatizada de bloqueio.

3. Impacto clínico e regulatório
O incidente pode:
•	violar confidencialidade, 
•	comprometer a confiança no serviço, 
•	dificultar investigação,
•	gerar responsabilização institucional diante de normas de proteção de dados e segurança
de DM ou softwares médicos.
•	expor:
1.	imagens identificáveis, 
2.	metadados clínicos,
3.	resultados de inferência. 

4. Mitigações propostas
•	Criar armazenamento exclusivamente por Terraform revisado.
•	Bloquear acesso público por padrão.
•	Obrigar criptografia, versionamento, logs e política de transporte seguro.
•	Impedir deploy caso OPA detecte bucket público ou sem criptografia.
•	Separar ambientes de desenvolvimento, homologação e produção.

5. Código 1 - Terraform para armazenamento clínico privado, criptografado e versionado

# secure_storage.tf - Exemplo didático de bucket privado para dados clínicos
terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

variable "bucket_name" {
  type        = string
  description = "Nome único do bucket para imagens e logs de IA médica."
}

resource "aws_s3_bucket" "clinical_ai" {
  bucket = var.bucket_name

  tags = {
    purpose       = "medical-ai"
    data_class    = "sensitive-health-data"
    managed_by    = "terraform"
    environment   = "production"
  }
}

resource "aws_s3_bucket_public_access_block" "clinical_ai" {
  bucket                  = aws_s3_bucket.clinical_ai.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_versioning" "clinical_ai" {
  bucket = aws_s3_bucket.clinical_ai.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "clinical_ai" {
  bucket = aws_s3_bucket.clinical_ai.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
    bucket_key_enabled = true
  }
}

resource "aws_s3_bucket_policy" "deny_insecure_transport" {
  bucket = aws_s3_bucket.clinical_ai.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "DenyInsecureTransport"
      Effect    = "Deny"
      Principal = "*"
      Action    = "s3:*"
      Resource  = [
        aws_s3_bucket.clinical_ai.arn,
        "${aws_s3_bucket.clinical_ai.arn}/*"
      ]
      Condition = { Bool = { "aws:SecureTransport" = "false" } }
    }]
  })
}

8. Cenário vulnerável 2: API de inferência de DMIA em cluster Kubernetes permissivo

1. Descrição

Uma unidade de terapia intensiva utiliza um serviço de inferência para prever 
deterioração clínica nas próximas horas. O serviço roda em:
•	Kubernetes com container privilegiado, 
•	service account padrão, 
•	comunicação aberta entre namespaces,
•	ausência de NetworkPolicy. 
Uma falha em componente periférico poderia permitir movimento lateral até 
a API de inferência.

2. Vulnerabilidades principais
•	Uso de service account padrão e token montado automaticamente.
•	Container sem securityContext restritivo.
•	Comunicação lateral sem segmentação.
•	Ausência de limites de recursos e controles de execução.
•	Logs clínicos e técnicos misturados sem segregação.

3. Impacto clínico e regulatório

O risco grave não é apenas vazamento. Um invasor ou erro operacional poderia 
alterar:
•	disponibilidade, 
•	latência,
•	entradas consumidas pelo modelo, gerando inferências atrasadas ou inconsistentes. 
Em ambiente crítico, atraso de alerta pode impactar tempo de resposta assistencial.

4. Mitigações propostas
•	Criar namespace específico para IA clínica.
•	Usar service account própria com automountServiceAccountToken desativado 
quando não houver necessidade.
•	Executar container como usuário não root, com filesystem somente leitura e 
capabilities removidas.
•	Aplicar NetworkPolicy permitindo apenas comunicação necessária.
•	Separar logs técnicos de dados clínicos e aplicar retenção mínima necessária.

5. Código 2 - Kubernetes YAML com execução não privilegiada e segmentação de rede

# k8s-medical-ai.yaml - Exemplo didático de hardening para API de inferência
apiVersion: v1
kind: Namespace
metadata:
  name: medical-ai-prod
  labels:
    purpose: medical-ai
    data-class: sensitive-health-data
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: inference-api-sa
  namespace: medical-ai-prod
automountServiceAccountToken: false
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-api
  namespace: medical-ai-prod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: inference-api
  template:
    metadata:
      labels:
        app: inference-api
    spec:
      serviceAccountName: inference-api-sa
      containers:
        - name: inference-api
          image: registry.example.org/medical-ai/inference-api:1.4.2
          ports:
            - containerPort: 8443
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "2"
              memory: "2Gi"
          securityContext:
            runAsNonRoot: true
            runAsUser: 10001
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: inference-api-allow-only-gateway
  namespace: medical-ai-prod
spec:
  podSelector:
    matchLabels:
      app: inference-api
  policyTypes: ["Ingress", "Egress"]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: clinical-gateway
      ports:
        - protocol: TCP
          port: 8443
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: observability
      ports:
        - protocol: TCP
          port: 4317

9. Cenário vulnerável 3: pipeline sem governança altera infraestrutura e modelo

1. Descrição

Um hospital utiliza pipeline de CI/CD para atualizar uma aplicação de triagem por IA. 
•	o repositório permite merge direto na branch principal, 
•	o plano Terraform não é revisado, 
•	segredos aparecem em variáveis,
•	artefatos de modelo são substituídos sem verificação de hash.

Uma alteração aparentemente pequena abre uma porta de rede e troca o modelo em produção
sem aprovação formal.

2. Vulnerabilidades principais
•	Ausência de proteção de branch e revisão obrigatória.
•	Plano Terraform não convertido para JSON e não avaliado por política.
•	Segredos ou tokens próximos do código e do estado.
•	Modelo sem verificação de integridade antes do deploy.
•	Falta de evidência auditável do que foi aprovado.

3. Impacto clínico e regulatório

Uma alteração não controlada pode modificar:
1.	rede, 
2.	permissões, 
3.	endpoints, 
4.	imagem de container,
5.	artefato de modelo. 

Isso fragiliza rastreabilidade e dificulta responder a perguntas fundamentais: 
•	qual versão inferiu o caso? 
•	quem aprovou? 
•	qual política foi executada? 
•	qual evidência demonstra que o ambiente estava conforme?

4. Mitigações propostas
•	Exigir pull request, revisão técnica e aprovação de segurança.
•	Executar terraform fmt, validate, plan e conversão do plano para JSON.
•	Validar o plano com OPA/Rego antes de permitir apply.
•	Adicionar verificação de hash e assinatura de artefatos de modelo.
•	Guardar evidências do pipeline como artefatos auditáveis.
•	

5. 1 Código 3A - Pipeline com validação Terraform e policy as code antes do merge

# .github/workflows/iac-security.yml - Pipeline didático de validação IaC
name: iac-security-gate

on:
  pull_request:
    branches: ["main"]

permissions:
  contents: read
  pull-requests: read
  id-token: write

jobs:
  terraform-security:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform format
        run: terraform fmt -check -recursive

      - name: Terraform init
        run: terraform init -backend=false

      - name: Terraform validate
        run: terraform validate

      - name: Terraform plan JSON
        run: |
          terraform plan -out=tfplan.binary
          terraform show -json tfplan.binary > tfplan.json

      - name: Install OPA
        run: |
          curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_amd64_static
          chmod +x opa

      - name: Policy as Code gate
        run: ./opa eval --fail-defined --data policy.rego --input tfplan.json 
"data.medical_iac.deny[_]"

      - name: Persist audit evidence
        uses: actions/upload-artifact@v4
        with:
          name: terraform-plan-and-policy-evidence
          path: |
            tfplan.json
            policy.rego


5. 2 Código 3B - Política Rego/OPA para bloquear ingresso público e buckets clínicos sem proteção

# policy.rego - Exemplo didático de regras OPA para bloquear riscos críticos
package medical_iac

default deny := []

# Bloqueia Security Groups com ingresso público em portas sensíveis.
deny[msg] {
  rc := input.resource_changes[_]
  rc.type == "aws_security_group_rule"
  rc.change.after.type == "ingress"
  rc.change.after.cidr_blocks[_] == "0.0.0.0/0"
  port := rc.change.after.from_port
  port == 22
  msg := sprintf("Acesso SSH público proibido em %s", [rc.address])
}

deny[msg] {
  rc := input.resource_changes[_]
  rc.type == "aws_security_group_rule"
  rc.change.after.type == "ingress"
  rc.change.after.cidr_blocks[_] == "0.0.0.0/0"
  port := rc.change.after.from_port
  port == 5432
  msg := sprintf("Banco de dados com ingresso público proibido em %s", [rc.address])
}

# Exige bloqueio de acesso público para buckets que contenham dados de saúde.
deny[msg] {
  rc := input.resource_changes[_]
  rc.type == "aws_s3_bucket"
  rc.change.after.tags.data_class == "sensitive-health-data"
  not public_access_block_exists(rc.change.after.bucket)
  msg := sprintf("Bucket clínico sem public access block: %s", [rc.address])
}

public_access_block_exists(bucket_name) {
  block := input.resource_changes[_]
  block.type == "aws_s3_bucket_public_access_block"
  block.change.after.bucket == bucket_name
  block.change.after.block_public_acls == true
  block.change.after.block_public_policy == true
  block.change.after.ignore_public_acls == true
  block.change.after.restrict_public_buckets == true
}

10. Matriz prática de governança IaC para IA médica

11. Quadro comparativo: mundo, Brasil e perspectivas futuras

12. Perspectivas futuras: da automação ao prontuário da IaC

A IaC  de IA médica tende a se tornar parte do dossiê de qualidade, segurança e tecnovigilância. 

No futuro, não bastará afirmar que um serviço é seguro; será necessário demonstrar, por evidências técnicas, 
que cada alteração foi:

•	planejada, 
•	revisada, 
•	testada, 
•	aprovada,
•	monitorada.

1. IaC como evidência regulatória: 
    Poderão compor dossiês técnicos de segurança:
•	logs,
•	planos, 
•	diffs, 
•	políticas.

2.	Policy as Code clínica: 
    Regras de conformidade poderão incluir requisitos assistenciais, como:
•	segregação de dados por finalidade,
•	restrição de inferência fora de contexto aprovado.


3.	MLOps regulado: 
    Deverão convergir com pipelines DevSecOps:
•	versionamento de modelo, 
•	dataset, 
•	métrica, 
•	drift,
•	provação clínica.

4.	Tecnovigilância computacional: 
    Eventos adversos poderão exigir:
•	reconstrução do estado da infraestrutura, 
•	versão do modelo,
•	trilha de inferência.

5.	Certificações de governança de IA: 
    Poderão orientar maturidade institucional;
•	ISO/IEC 42001,
•	Estruturas correlatas.

6.	Formação híbrida: 
    Precisarão de linguagem comum:
•	médicos, 
•	engenheiros, 
•	analistas de segurança, 
•	DPOs,
•	gestores.

13. Checklist operacional

|Item|Controle esperado|Status sugerido|

|Repositório|Branch protegida, revisão obrigatória, commits assinados e histórico preservado|
|Obrigatório em produção clínica|

|Terraform|fmt, validate, plan, estado remoto protegido, código sem variáveis sensíveis e módulos revisados|	
|Obrigatório em produção clínica|

|OPA/Rego|Bloquear exposição pública, ausência de criptografia, portas sensíveis abertas e permissões amplas|
|Obrigatório em produção clínica|

|Segredos|Uso de cofre de segredos, rotação, ausência de segredo em código, logs ou arquivos de estado|
|Obrigatório em produção clínica|

|Kubernetes|Containers não privilegiados, RBAC mínimo, NetworkPolicy, fixar imagens com tags, controlar logs|
|Obrigatório em produção clínica|

|Modelo de IA|Registro de versão, hash, métrica, data de aprovação, escopo clínico e plano de rollback|	
|Obrigatório em produção clínica|

|Dados|Classificação, minimização, criptografia, retenção, pseudonimização e registro de acesso|
|Obrigatório em produção clínica|

|Auditoria|Artefatos do pipeline preservados: plano, política, resultado dos testes, aprovação e evidência de deploy|
|Obrigatório em produção clínica|

14. Discussão

A contribuição central deste artigo é afirmar que a IaC digital da medicina assistida por IA deve ser tratada 
como componente crítico do sistema clínico, e não como camada operacional invisível. 

Em ambientes hospitalares tradicionais, falhas em esterilização, administração de medicamentos, 
identificação de pacientes ou comunicação são classificadas como riscos assistenciais. 

No contexto de IA, elementos como buckets, service accounts, pipelines, modelos, logs e redes passam a 
integrar o mesmo domínio de risco, pois influenciam diretamente a segurança do paciente.

Embora IaC reduza variabilidade e padronize ambientes, ela não elimina riscos, pois código também erra. 
O valor real está no ecossistema de governança técnica: revisão por pares, validação automatizada, 
políticas como código, segregação de ambientes, observabilidade e práticas DevSecOps.

O objetivo é garantir que nenhuma mudança relevante alcance o ambiente clínico sem evidência 
mínima de conformidade.

No Brasil, a LGPD, as normas da ANVISA para SaMD e dispositivos médicos, e o avanço de um marco
regulatório de IA criam um cenário propício para pesquisa aplicada. 

A lacuna está em traduzir essas exigências em controles técnicos verificáveis. 

Nesse sentido, IaC pode atuar como interface entre:

1. legislação,
2. qualidade,
3. segurança da informação,
4. engenharia,
5. prática assistencial.

15. Considerações Finais

Encerrar o curso de Infrastructure as Code com um artigo voltado à medicina assistida por IA é reconhecer
que a nuvem não é neutra no cuidado. 

A IaC define onde dados sensíveis residem, quem pode acessá-los, como modelos são atualizados, como 
incidentes são investigados e qual evidência existe para sustentar a confiança clínica.

•	Automatizar sem proteger pode acelerar o erro. 

•	Padronizar sem auditar pode ocultar fragilidades. 

•	Implantar IA sem governar infraestrutura pode transformar inovação em risco assistencial. 

O caminho tecnicamente maduro é integrar IaC, DevSecOps, GitOps, policy as code, tecnovigilância 
e governança de IA em uma mesma linguagem operacional.

A proposta final deste artigo é simples e exigente: toda infraestrutura que sustenta IA médica deve 
poder responder a cinco perguntas fundamentais: 

1.	o que foi alterado
2.	por quem, 
3.	quando, 
4.	por qual motivo,
5.	com qual evidência de segurança. 

Quando a infraestrutura consegue responder, ela deixa de ser bastidor e se torna parte documentada da
proteção do paciente.

16. Referências técnicas e regulatórias consultadas

[1] HashiCorp. Terraform documentation: infrastructure as code tool for building, changing and versioning infrastructure safely and efficiently. https://developer.hashicorp.com/terraform

[2] OWASP. Infrastructure as Code Security Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html

[3] Open Policy Agent. Policy Language / Rego documentation. https://openpolicyagent.org/docs/policy-language

[4] NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). https://www.nist.gov/itl/ai-risk-management-framework

[5] ISO. ISO/IEC 42001:2023 Artificial intelligence management systems. https://www.iso.org/standard/42001

[6] European Commission. AI Act regulatory framework and application timeline. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

[7] U.S. FDA. Artificial Intelligence in Software as a Medical Device. https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-software-medical-device

[8] ANVISA. RDC nº 657, de 24 de março de 2022: regularização de Software como Dispositivo Médico (SaMD). https://anvisalegis.datalegis.net/action/ActionDatalegis.php?acao=abrirTextoAto&numeroAto=00000657&tipo=RDC&valorAno=2022

[9] ANVISA. RDC nº 751, de 15 de setembro de 2022: classificação de risco, rotulagem e regularização de dispositivos médicos. https://anvisalegis.datalegis.net/action/ActionDatalegis.php?acao=abrirTextoAto&numeroAto=00000751&tipo=RDC&valorAno=2022

[10] Presidência da República. Lei nº 13.709/2018 - Lei Geral de Proteção de Dados Pessoais (LGPD), texto compilado. https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709compilado.htm

[11] Senado Federal. PL 2338/2023 - dispõe sobre o uso da Inteligência Artificial. https://www25.senado.leg.br/web/atividade/materias/-/materia/157233

[12] ANVISA. Software como dispositivo médico: perguntas e respostas - RDC 657/2022. https://www.gov.br/anvisa/pt-br/assuntos/noticias-anvisa/2022/software-como-dispositivo-medico-perguntas-e-respostas/perguntas-respostas-rdc-657-de-2022-v1-01-09-2022.pdf

Oi, Ricardo! Tudo bem?

Gostei de ver você relacionando Infrastructure as Code na Medicina Assistida por IA com temas como DevSecOps, GitOps e segurança em ambientes de saúde, ampliando os conceitos apresentados no curso para um contexto de alta relevância.

Seu projeto demonstra uma boa integração entre práticas de governança, automação e auditabilidade, conectando conceitos técnicos com aplicações voltadas à proteção de sistemas de IA na área médica. A organização do material, o uso de cenários práticos e a preocupação com normas e boas práticas enriquecem bastante a proposta.

Pensando na evolução desse projeto, quais outros cenários de infraestrutura ou segurança em saúde você pretende explorar utilizando Infrastructure as Code?

Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Olá, Lorena. Você está cada vez mais aprofundando seus conhecimentos em Medicina e IA. Seus comentários são
extremamente pertinentes dentro do contexto. Depois daquele artigo, finalizei hoje mais um, cujo tema central é o
Monitoramento em Nuvem da Assistência Médica com IA.

Nesta fase dos meus estudos, estou focando na interseção entre Medicina, IA e Cibersegurança.

Atenciosamente,
Ricardo