Amazon Quick으로 HIPAA 적격 환경에서 AI를 배포하세요

의료 기관이 AI에 바라는 것은 다른 모든 비즈니스와 마찬가지입니다. 더 빠른 답변, 더 적은 수작업, 그리고 의사 결정권자에게 제때 도달해 실행할 수 있는 인사이트입니다. 다만 의료 산업을 특별하게 만드는 것은 데이터가 유례없이 복잡하고, 깊은 맥락을 지니며, 엄격하게 규제된다는 점입니다. 그래서 이 글은 이후의 모든 내용의 기초를 다지기 위해 몇 가지 정의부터 시작합니다.

보호 건강 정보(PHI)는 사람을 식별할 수 있고 그 사람의 건강, 진료 또는 진료 비용과 관련된 정보로, 의료 기록, 청구서 또는 회원 ID 등이 이에 해당합니다. 소프트웨어가 PHI를 다루는 경우, PHI 데이터의 접근, 보안 및 감사를 규정하는 연방 법률인 건강 보험 이식성과 책임에 관한 법률(HIPAA)의 적용을 받게 됩니다.

에이전트형 AI는 소프트웨어가 “PHI를 다루는 것”의 의미를 바꿉니다. 기존의 분석 도구는 데이터를 읽고 응답을 반환합니다. 반면 에이전트형 워크스페이스는 Amazon Quick 더 나아갈 수도 있습니다. 예를 들어, 이 회사의 챗 에이전트는 임상 노트와 항의 서신과 같은 비정형 콘텐츠와 클레임 및 회원 기록과 같은 정형 데이터 모두에서 작동합니다. 에이전트는 비정형 소스와 정형 소스 양쪽에서 데이터를 검색하고, 커넥터를 통해 다른 시스템을 호출하며, 사용자를 대신해 다단계 작업을 완료할 수 있습니다. 커넥터 Amazon Quick가 외부 시스템(예: Slack, 마이크로소프트 Outlook, Salesforce, Atlassian Jira, 그리고 마이크로소프트 SharePoint. Model Context Protocol(MCP)를 통해 자체 사용자 지정 도구를 추가할 수도 있습니다. 조직 내에서 승인된 커넥터만 표시됩니다. 챗 에이전트가 PHI를 읽고 동시에 조작할 수 있는 경우, 결정론적 가드레일, 에이전트가 수행한 작업에 대한 행동 감사 추적, 그리고 사람이 개입하지 않은 상태에서 수행된 작업에 대한 명확한 책임 소재와 같은 충분한 거버넌스가 필요합니다. 이러한 거버넌스를 지원하기 위해 Amazon Quick는 ACL을 인식하는 검색, 채팅 및 피드백 로깅, 그리고 각 챗 에이전트가 수행할 수 있는 작업에 대한 제어 기능을 제공합니다.

Amazon Quick는 HIPAA-대상 서비스입니다. 이 적용 대상은 공동 책임 모델 및 귀하의 구성에 따라 Amazon Quick 웹, 데스크톱 및 모바일 클라이언트 전반에 적용됩니다. 다만 이 게시물은 브라우저를 통해 접속하는 Amazon Quick 웹 버전의 기능에 중점을 둡니다.

이 게시물에서는 먼저 기초를 다룹니다. HIPAA가 적용되는 대상과 HIPAA 적격(HIPAA-eligible)과 HIPAA 준수(HIPAA-compliant)의 차이점입니다. 그런 다음 Amazon Quick를 플랫폼으로 소개하고 PHI(비정형 및 정형)에 대한 두 가지 데이터 흐름을 설명합니다. 이어서 Amazon Quick가 규제 환경에서 제공하는 것과 제공하지 않는 것을 다루고, 가상의 건강 보험 회사(AnyCompany)의 배포 사례를 살펴보며, 사전에 결정해야 할 모범 사례와 되돌릴 수 없는 결정들을 정리합니다. 마지막으로 단계별 구현 가이드, 결론, 그리고 심화 학습을 위한 자료로 마무리합니다.

HIPAA는 누구에게 적용되나요?

HIPAA는 병원과 진료소를 넘어 더 넓게 적용됩니다. 법률에 따라 두 가지 범주의 조직이 의무를 지며, 대부분의 AI 프로젝트는 이 둘 모두에 해당합니다.

보호 대상 기관(CEs)

• 건강 보험 플랜 – 건강보험 회사, HMO, 고용주 제공 플랜, Medicare 및 Medicaid.
• 의료 정보 중개기관 – 비표준 보건 정보를 표준 전자 형식으로 변환 처리하는 기관.
• 의료 제공자 – 의사, 클리닉, 병원, 약국, 요양원 및 건강 정보를 전자적으로 전송하는 모든 의료 제공자.

사업 제휴사(BAs)

• 업무 제휴자(business associate)란, 규제 대상 기관(covered entity)의 인력 외부에서 규제 대상 기관을 대신하여 보호 건강 정보(PHI)를 생성, 수신, 유지 또는 전송하는 모든 개인 또는 단체를 말합니다.
• 일반적인 예로는 클라우드 서비스 제공업체, IT 벤더, 청구 회사, 데이터 분석 회사, 클레임 처리업체, 로펌 및 컨설팅 회사가 있습니다.
• 다른 사업자를 대신하여 PHI를 취급하는 하청업체는 그 자체로 사업자입니다.

Covered entity와 business associate는 PHI가 인수인계되기 전에 반드시 business associate addendum(BAA)에 모두 서명해야 합니다. AWS Artifact를 통해 AWS BAA를 수락하면 AWS는 해당 특정 AWS 계정에 대해서만, 그리고 Amazon Quick과 같은 HIPAA 적격 서비스를 사용해 그 안에서 PHI를 처리할 때에만 귀하의 business associate로 활동합니다. 이 addendum는 귀하의 다른 계정, HIPAA 적격이 아닌 서비스에 배치된 PHI, 또는 서비스 구성 방식까지는 적용되지 않습니다. 이러한 사항은 귀하의 책임으로 남습니다. 항상 최신 AWS BAA 조건과 귀하의 의무를 자신의 법무 및 컴플라이언스 팀과 함께 검토하고 확인하십시오.

HIPAA 적격(HIPAA eligible)은 HIPAA 준수(HIPAA compliant)와 같지 않습니다

HIPAA eligible는 AWS의 지정(designation)이지만, HIPAA compliant는 귀하의 전체 환경의 속성입니다. HIPAA eligible은 AWS가 해당 서비스를 평가했으며, 서명된 AWS BAA 하에서 PHI를 처리, 저장 및 전송하는 데 이를 사용할 수 있도록 허용한다는 의미입니다. Amazon Quick는 HIPAA eligible 서비스이며, 제3자 감사기관이 HIPAA, FedRAMP, PCI DSS, SOC, ISO를 포함한 AWS 규정 준수 프로그램에 따라 이를 평가합니다. 클라우드 서비스로서의 AWS에 대한 공식 HIPAA 인증은 존재하지 않으며, AWS 자체는 “HIPAA eligible”이 아닙니다.

Amazon Quick의 eligibility는 어디까지나 구성 요소일 뿐입니다. 그것만으로 귀하의 애플리케이션과 환경이 HIPAA를 준수하게 되는 것은 아닙니다. 여전히 BAA에 서명하고, 데이터를 분류하고, 통제 장치를 올바르게 구성해야 하며, 인력 교육, 위험 분석, 침해 사고 절차 등 AWS가 대신 수행해 주지 않는 HIPAA가 요구하는 관리적·물리적 안전 조치를 직접 책임져야 합니다. Amazon Quick와 같은 eligible 서비스, 서명된 BAA, 올바른 구성, 거버넌스, 그리고 귀하 자신의 안전 조치가 갖추어져야 비로소 HIPAA를 준수하는 배포가 완성됩니다. Amazon Quick가 eligible하다는 것은 그 위에 규정을 준수하는 워크플로를 구축할 수 있다는 의미이며, 기능을 켜는 것만으로 자동으로 준수 상태가 된다는 의미가 아닙니다.

Amazon Quick란 무엇인가

Amazon Quick는 흔히 챗 에이전트를 통해 소개되지만, HIPAA eligibility는 단일 기능이 아니라 전체 작업 공간(workspace)에 적용되므로 규정 준수를 위해서는 플랫폼 수준의 관점이 중요합니다. Amazon Quick의 모든 기능은 다음의 구성 요소들로 조립됩니다:

• Chat 은 기본 인터페이스입니다. 사용자가 자연어로 질문을 하거나 지시를 내리면, Amazon Quick가 응답 방식을 결정합니다.
• Chat agents 가 모든 요청을 처리합니다. 이것이 콘솔의 Chat agents 메뉴에서 볼 수 있는 것입니다. 각 챗 에이전트는 지시 사항으로 구성하고, 지식 소스로 근거를 확보하며, 작업을 수행할 도구를 부여할 수 있습니다. Amazon Quick는 기본 챗 에이전트(My Assistant)를 제공하며, 특정 도메인을 위한 사용자 지정 챗 에이전트를 만들 수도 있습니다.
• Spaces 는 문서, 대시보드, 데이터셋, 지식 베이스, 액션 커넥터 등 챗 에이전트에 필요한 리소스를 조직화합니다. 스페이스는 팀과 공유할 수 있습니다.
• Integrations 는 Amazon Quick를 귀하의 환경과 연결합니다: knowledge bases 는 다음과 같은 비정형 콘텐츠를 위한 것으로, Amazon Simple Storage Service (Amazon S3), Microsoft SharePoint, 그리고 Atlassian Confluence가 있습니다. 또한 Amazon Quick Sight를 구조화된 데이터베이스, 데이터 웨어하우스, 데이터 레이크에 연결하는 구조화 데이터 연결, 액션 커넥터(OpenAPI 사양 또는 Model Context Protocol 서버로 구축), 그리고 확장 기능(Chrome, Slack, Microsoft Teams, Microsoft 365)이 있습니다.

  이러한 구성 요소들 위에 개별 기능들이 놓입니다. What it draws on 열은 각 기능이 어떤 구성 요소, 즉 어떤 데이터 경로를 사용하는지 보여주기 때문에 규정 준수 측면에서 중요합니다.

참고: SPICE는 Amazon Quick Sight의 인메모리 쿼리 엔진입니다. SPICE 데이터세트는 생성 시 계정 기본 고객 관리형 키를 사용하며, 기존 데이터세트를 새 기본 키로 가져오려면 전체를 수행해야 합니다. 새로 고침데이터에 PHI가 포함된 경우 암호화 전략에 SPICE를 포함하세요(고객 관리형으로 보호하세요. AWS Key Management Service (KMS) 키를 사용하는 경우 해당 키) 그리고 무엇을 가져올지에 대한 데이터 최소화 결정, 예를 들어 라이브 쿼리 대신 비식별화된 추출본을 로드하는 방식에도 적용됩니다.

동일한 자격 요건, BAA, 암호화, 접근 제어 및 감사 체계가 모든 기능에 걸쳐 적용됩니다. 그러나 앞서 언급했듯이, PHI는 두 가지 경로를 통해 Amazon Quick에 도달하며 각 경로는 서로 다르게 보호됩니다. 비정형 경로는 지식 베이스를 통해 진행되며, 여기서 문서는 문서 수준 ACL로 제어되고 쿼리 시점에 평가됩니다. 정형 경로는 다음을 통해 진행됩니다. Amazon Quick Sight 데이터베이스와 데이터 레이크를 읽는 과정으로, 여기서는 행 및 열 접근이 행 수준 및 열 수준 보안에 의해 통제됩니다. 이 두 데이터 흐름은 PHI를 서로 다르게 처리하며, 다음 섹션에서 보여지듯이 각 경로에서 통제가 서로 다르게 적용됩니다.

Amazon Quick가 규제 대상 환경을 위해 제공하는 것

Amazon Quick는 HIPAA 적격 서비스이며, 이것이 실무에서 무엇을 의미하는지 설명합니다.

관리형 인프라

Amazon Quick는 완전관리형 서비스입니다. AWS는 기반이 되는 인프라를 운영하며 클라우드 자체의 보안에 대한 책임을 지고, 이는 다음에 명시된 바와 같이 제3자 감사기관을 통해 검증됩니다. AWS Shared Responsibility Model.

암호화

Amazon Quick는 기본적으로 저장 데이터를 암호화하며 전송 중 데이터에 대한 암호화를 지원합니다.

• 저장 데이터 암호화는 AWS 소유 키 또는 AWS 관리형 키를 사용하여 기본적으로 활성화됩니다. 고객 관리형 키를 등록하는 것은 선택 사항이며 HIPAA 요건은 아닙니다. 암호화 키에 대한 직접적인 통제가 필요한 경우, SPICE 데이터세트, 데이터 소스 자격 증명, OAuth 토큰, 보고서 아티팩트를 포함한 해당되는 리소스 유형에 대해 고객 관리형 AWS KMS 키를 등록할 수 있습니다(Enterprise 구독 필요). 고객 관리형 키가 적용되지 않는 경우, AWS는 AWS 소유 키 또는 AWS 관리형 키로 데이터를 암호화합니다.
• 한 가지 주의할 뉘앙스: 선택적 자유 텍스트 코멘트를 포함하여 채팅 응답에 대한 사용자 피드백은 고객 관리형 키 또는 Amazon Quick의 AI 인덱싱 데이터를 보호하는 키로 암호화되지 않습니다. 사용자 피드백은 잠재적 PHI 노출 면으로 취급하고 그에 맞게 거버넌스를 적용해야 합니다.
• 전송 중 데이터의 경우, Amazon Quick는 Transport Layer Security(TLS)로 암호화된 전송을 보호합니다. 일부 데이터베이스 연결에서는 전송 암호화 여부를 선택할 수 있으므로, 항상 활성화되어 있다고 가정하지 말고 해당 데이터 소스 연결에서 TLS/SSL을 명시적으로 활성화해야 합니다.

고객의 데이터는 모델을 학습시키지 않습니다

Amazon Quick는 고객 데이터를 사용하여 기반이 되는 대규모 언어 모델(LLM)을 학습시키거나 개선하지 않습니다.

접근 통제 및 아이덴티티 페더레이션

Amazon Quick는 AWS IAM Identity Center, Microsoft Active Directory, SAML 2.0 아이덴티티 공급자를 통한 역할 기반 접근 통제(RBAC)와 싱글 사인온(SSO)을 지원합니다. 비즈니스 인텔리전스(BI) 워크로드의 경우, 행 수준 및 열 수준 보안과 run-as 역할을 보완하여 쿼리 시점에 데이터 접근을 제한할 수 있습니다. 이러한 기능을 통해 고유한 사용자 식별과 최소 권한 원칙을 적용할 수 있습니다.

감사 및 모니터링 신호

Amazon Quick는 여러 가지 서로 다른 신호를 발생시킵니다. 이들은 서로 호환되지 않으며, 이를 혼동하는 것이 흔한 감사 공격점입니다.

• AWS CloudTrail 지원되는 API 작업과 대시보드 조회 및 사용자 관리 작업 같은 문서화된 비-API 이벤트 집합을 기록합니다. 누가 언제 무엇을 했는지는 포착하지만, 채팅 메시지 본문이나 응답 내용은 포착하지 않습니다.
• Amazon CloudWatch vended 로그는 AI 관련 레코드를 사용자가 제어하는 대상(CloudWatch Logs, Amazon S3 또는 Firehose)으로 전달합니다. 로그 유형은 다섯 가지입니다: 채팅 대화(CHAT_LOGS), 사용자 피드백(FEEDBACK_LOGS), 에이전트 및 리서치 시간(AGENT_HOURS_LOGS), 인덱스 스토리지 사용량(INDEX_USAGE_LOGS), 지식 베이스 파일 동기화(KB_FILE_SYNC_LOGS). "사용자가 무엇을 물었고 Amazon Quick가 무엇으로 답했는지"에 대한 정보는 CloudTrail이 아니라 여기에 기록됩니다.
• CloudWatch 지표와 알람은 거의 실시간에 가까운 운영 모니터링도 제공합니다.
• 분석 대시보드는 관리자에게 사용량과 도입 현황을 보여줍니다. 부정적 피드백 검토 범위에서 상세한 쿼리 텍스트와 전체 대화 맥락이 노출될 수 있으므로, 승인된 관리자에게만 접근 권한을 부여하십시오.

채팅 로그와 피드백에는 PHI가 포함될 수 있으므로 CloudWatch Logs 데이터 보호 마스킹을 적용하고, 규정 준수를 위해 이를 사용하기 전에 해당 신호가 실제로 추적하려는 이벤트를 포괄하는지 확인하십시오.

기능을 HIPAA 통제 항목으로 전환하기

Amazon Quick가 적격 서비스라는 점은 유용합니다. 다음 표와 같이 각 기능을 특정 HIPAA 보호 조치에 매핑할 수 있기 때문입니다:

Amazon Quick이 하지 않는 것

Amazon Quick은 앞서 언급한 통제 기능을 제공하지만, 이 섹션에서는 Amazon Quick이 제공하지 않는 것과 이 격차를 메우는 방법을 다룹니다. Amazon Quick은 접근, 검색, 상호작용을 관리합니다. 이는 데이터 엔지니어링 또는 데이터 레이크 거버넌스 플랫폼이 아닙니다. HIPAA 맥락에서 여러 요구 사항은 Amazon Quick의 범위를 벗어나며, Amazon Quick 상류의 다른 AWS 서비스에 의해 충족됩니다.

• 비식별화 및 변환. Amazon Quick은 PHI를 비식별화하거나 원본 데이터를 재구성하지 않습니다. 사용 사례에 제한적 데이터 세트 또는 비식별화된 추출이 필요한 경우, 적절한 AWS 서비스를 사용하여 Amazon Quick에 도달하기 전에 데이터를 준비해야 합니다. 예를 들어 시각적 데이터 준비 및 편집(redaction)을 위한 AWS Glue DataBrew(AWS Glue의 기능) 또는 추출, 변환, 적재(ETL) 파이프라인을 위한 AWS Glue 를 사용할 수 있습니다.
• 데이터 레이크 거버넌스 및 세분화된 테이블 권한. Amazon Quick Sight가 데이터 레이크를 통해 쿼리하는 구조화된 데이터의 경우, 레이크 자체에 대한 열 및 행 수준 거버넌스의 역할은 Amazon Quick이 아니라 AWS Lake Formation에 있습니다. Amazon Quick Sight는 분석 계층에서 자체적인 행 수준 및 열 수준 보안을 적용하지만, 권위 있는 레이크 수준의 권한 부여는 Lake Formation과 AWS Glue Data Catalog에 있습니다.
• 관리적 및 물리적 보호 조치. 인력 교육, 위험 분석, 침해 절차는 도구와 관계없이 사용자의 책임으로 남습니다.

일반적인 모범 사례는 책임을 구분하고 상류 서비스가 어떤 데이터가 존재하는지와 소스에서 누가 쿼리할 수 있는지를 결정하도록 하는 것입니다. Amazon Quick이 누가 질문할 수 있는지와 에이전트가 데이터로 무엇을 할 수 있는지를 결정하도록 하십시오.

AnyCompany Health Plan: 샘플 사용 사례

가상의 건강 보험 플랜인 AnyCompany Health Plan은 하나의 사용 사례와 패턴을 보여줍니다. AnyCompany Health Plan은 두 가지를 원하는 커버드 엔티티(covered entity)입니다. 케어 관리 팀이 자연어로 정책 및 회원 이의 제기 문서에 대해 질문할 수 있게 하는 것과, 운영 리더에게 청구 데이터 기반의 셀프서비스 대시보드를 제공하는 것입니다. 두 가지 모두 PHI와 관련되므로 AnyCompany는 솔루션이 HIPAA를 준수하는지 확인해야 합니다. AnyCompany의 환경에는 두 개의 데이터 경로가 있으며, Amazon Quick이 데이터에 접근하기 전에 각 경로는 서로 다른 솔루션으로 설계되고 거버넌스가 적용됩니다.

비구조화 경로 (정책 및 의료 기록 문서)

→ Amazon S3 버킷(ACL 인식 KB 소스)

→ Amazon Quick Knowledge Base(문서 수준 ACL, 쿼리 시 fail-closed)

구조화 경로(청구 데이터)

현재 모든 청구 데이터는 레이크(Amazon S3)에 있습니다.

→ Glue ETL(큐레이션) → Glue DataBrew(비식별화)

→ Lake Formation(행/열 권한 및 AWS Glue Data Catalog)

→ Amazon Quick Sight 데이터셋(Amazon Athena)(행 수준 및 열 수준 보안, run-as 역할)

앞서 설명한 구조화 데이터와 비구조화 데이터를 위한 두 데이터 흐름은 모두, 연동 SSO, 최소 권한 공간, 가드레일, CloudWatch 제공 로그를 갖춘 Amazon Quick 챗 에이전트로 수렴합니다.

AnyCompany의 관리자가 이 솔루션을 구현하는 방법은 다음과 같습니다:

1. BAA에 서명하고 다음을 통해 프로비저닝하십시오: AWS 관리 콘솔. 관리자는 AWS Artifact에서 AWS 계정에 대해 AWS BAA에 동의한 후, AWS Management Console에서 IAM Identity Center를 사용하여 Amazon Quick를 프로비저닝합니다. AnyCompany는 규정 준수 대장에 계약 ID, 타임스탬프 및 계정을 기록합니다. AWS Management Console을 통해 프로비저닝된 Amazon Quick의 웹 버전만이 AWS Artifact를 통해 서명된 BAA의 적용 대상이 될 수 있으며, 이는 PHI를 다루는 HIPAA 준수 워크플로를 구축하는 고객에게 필수적인 요소입니다. 단, 이는 적절한 구성과 고객 자신의 규정 준수 책임을 전제로 합니다.
2. 첫날부터 되돌릴 수 없는 통제를 설정하십시오. AnyCompany의 보안 정책이 자체 암호화 키 통제를 요구하기 때문에 관리자는 Amazon Quick AI 데이터가 생성되기 전에 고객 관리형 키를 계정 기본값으로 등록하기로 선택합니다. 데이터 키는 한 번 설정되면 나중에 변경할 수 없습니다. (기본 AWS 관리형 암호화도 HIPAA 적격입니다. 고객 관리형 키 사용은 서비스가 HIPAA 적격이 되기 위한 필수 조건이 아닙니다.) 관리자는 또한 비활성 사용자 감지가 적용되도록 IAM Identity Center로 자격 증명 모델을 정합니다. Amazon Quick 데이터 키는 한 번 설정 처음 데이터 생성 시 설정되며 이후에는 절대 변경할 수 없습니다. 키가 삭제되면 구독을 취소하고 다시 구독하는 것만이 유일한 복구 방법이며, 이 경우 모든 Amazon Quick 데이터가 영구적으로 삭제됩니다.
3. Amazon Quick 외부에서 구조화된 경로를 준비하세요. Amazon Quick Sight가 청구 데이터를 다루기 전에 AnyCompany의 데이터 팀은 AWS Glue를 사용하여 정제된 청구 테이블을 구축하고, Glue DataBrew를 사용하여 운영 대시보드용으로 식별 정보가 제거된 추출물을 생성합니다. AWS Lake Formation은 AWS Glue Data Catalog를 통해 해당 테이블에 대한 행 및 열 수준 액세스를 부여합니다. 그 결과 Amazon Quick은 불필요한 원시 PHI를 전혀 보지 못합니다.
4. 문서에 대해 ACL을 인식하는 지식 베이스를 생성합니다. 관리자는 생성 시점에 문서 수준 ACL을 활성화하여 정책 및 이의신청(policy-and-appeals) S3 버킷을 지식 기반으로 연결합니다. ACL은 나중에 활성화할 수 없으므로 S3 버킷을 생성할 때 이를 구성해야 합니다. Amazon Quick는 쿼리 시점에 각 사용자의 신원을 평가하며, 접근 권한을 확인할 수 없으면 문서를 반환하지 않습니다.
5. 전용 공간과 맞춤형 챗 에이전트를 구축하세요. AnyCompany는 일반 생산성 스페이스와 별도로, 멤버십이 제한된 PHI 스페이스를 생성합니다. 케어 관리 챗 에이전트는 ACL 인식 지식 베이스만 범위로 지정받고, 일반 웹 검색은 비활성화되며 가드레일이 구성됩니다. PHI와 관련된 모든 항목에는 읽기 전용 커넥터가 구현됩니다.
6. 쿼리 시점 보안으로 대시보드를 연결하세요. 운영 대시보드는 Athena를 통해 비식별화된 Amazon Quick Sight 데이터 세트를 읽으며, Amazon Quick Sight의 행 수준 및 열 수준 보안과 run-as 역할이 Lake Formation 권한 위에 계층화되어 적용됩니다.
7. 사용자를 온보딩하기 전에 감사 신호를 켜십시오. 관리자는 CloudTrail 트레일을 생성하고 CloudWatch vended 로그 전송(CHAT_LOGS, FEEDBACK_LOGS, KB_FILE_SYNC_LOGS 및 나머지)을 보존 및 마스킹이 적용된 대상으로 구성합니다. 피드백은 PHI 표면으로 취급됩니다.
8. 검증한 후 비-PHI에서 PHI로 확장하십시오. AnyCompany는 거버넌스를 확인하기 위해 정책 Q&A 및 문서 검색과 같은 비-PHI 워크플로로 시작하고, fail-closed ACL 동작을 검증하기 위해 적대적 프롬프트로 테스트하며, 이벤트가 캡처되었는지 확인하기 위해 로그를 검토한 후에야 케어관리 팀을 PHI 인접 업무로 확장합니다.

   Amazon Quick는 아이덴티티, 검색, 가드레일, 그리고 감사 추적을 강제합니다. 하지만 비식별화, ETL, 그리고 레이크 수준의 권한 부여는 업스트림의 Glue, Glue DataBrew, Lake Formation에서 이루어집니다. 이러한 역할 분담이 권장되는 패턴이며, 연합(federated) 환경에서 Amazon Quick를 보강하는 실용적인 해답입니다.

규정 준수 방법: 모범 사례

자격 요건이 있다면 여러분에게 플랫폼을 제공합니다. ~할 수 있다 PHI를 처리합니다. 여전히 다음과 같이 구성해야 합니다. 그렇습니다.

이 섹션은 관련된 공동 책임 결정을 이해하는 데 도움을 줍니다. 이러한 결정 중 일부는 되돌릴 수 없으므로, 리소스를 생성하거나 사용자를 온보딩하기 전에 결정하시기 바랍니다.

에이전틱 AI를 위한 보안 모델부터 시작하십시오

Amazon Quick 에이전트는 매 단계마다 지시를 기다리지 않습니다. 이들은 스스로 도구를 호출하고, 데이터를 수정하며, 외부 시스템과 상호작용합니다. 이는 환경을 보호하는 방식에 변화를 가져옵니다. AWS 게시됨 2026년 4월에 발표된 에이전틱 AI를 위한 4가지 보안 원칙이 있으며, 이는 여기에 직접 적용됩니다.

원칙 1 — 기존 보안 프레임워크 위에 에이전트 보호 장치를 계층화하세요. Amazon Quick를 위한 별도의 보안 체계를 구축하지 마세요. 이미 적용하고 있는 IAM, 네트워크 및 암호화 정책 위에 에이전트 전용 조치(가드레일, 주제 차단, PII 삭제)를 추가하세요.

원칙 2 — 프롬프트 기반 통제보다 결정론적 통제를 신뢰하십시오. 잘 설계된 적대적 입력은 프롬프트 지시를 우회할 수 있습니다. AWS Identity and Access Management (IAM) 정책, 문서 수준 ACL, 네트워크 경계, 관리자가 구성한 가드레일은 말로 회유할 수 없습니다. 이것들을 1차 집행 수단으로 사용하십시오. 에이전트 지시는 두 번째 계층이지 유일한 계층이 아닙니다.

원칙 3 — 인지(perceive), 추론(reason), 행동(act) 전반에 걸쳐 다층 방어를 적용하십시오. 모든 에이전트 기능을 세 계층 중 하나에 매핑하십시오:

• 인지(Perceive): 지식 베이스, 업로드된 파일, 웹 검색, 커넥터 입력, MCP 도구 출력.
• 원인: 가드레일과 주제 제어에 의해 통제되는 LLM 처리 컨텍스트.
• Act(실행): 커넥터, Quick Flows, Quick Automate, 예약 작업, MCP 도구 호출.

각 계층에 제어를 독립적으로 적용하십시오. 한 계층의 공백이 다른 계층으로 연쇄적으로 확산되어서는 안 됩니다.

HIPAA BAA 의무는 MCP 도구와 같은 지원 서비스 및 솔루션에도 적용된다는 점에 유의하십시오.

원칙 4 — 자율성을 점진적으로 확대합니다. 에이전트를 비(非)PHI 데이터에 대해 읽기 전용 모드로 시작하십시오. 기능을 한 번에 하나씩 추가하십시오. 다음 단계로 이동하기 전에 각 단계에서 데이터 유출, 프롬프트 인젝션 저항성, 권한 경계 준수를 테스트하십시오.

배포 전에 결정하십시오

이 세 가지 선택은 되돌릴 수 없으므로, 구현 전에 이러한 결정을 내리십시오.

KMS 키를 먼저 등록하십시오. 조직에서 자체 암호화 키에 대한 통제를 요구하는 경우, Amazon Quick AI 리소스를 생성하기 전에 고객 관리형 키를 계정 기본값으로 등록하십시오. 데이터 키는 계정에서 Quick AI 데이터가 처음 생성될 때 설정되며, 그 이후에는 변경할 수 없습니다. 고객 관리형 키 지원에는 Enterprise 구독이 필요합니다. 고객 관리형 키는 채팅 메모리를 비활성화한다는 점에 유의하십시오. 고객 관리형 키로 구성된 계정은 이 기능을 지원하지 않습니다.

신원(identity) 모델을 신중하게 선택하십시오. 네 가지 옵션이 있습니다: IAM Identity Center, Active Directory, IAM 페더레이션, Quick 로컬 사용자. 이들은 프로비저닝, 오프보딩, 거버넌스 동작이 다릅니다. 예를 들어, 비활성 사용자 감지는 IAM Identity Center 또는 Active Directory에서만 작동합니다. 배포 후에 신원 공급자를 전환하면 모든 사용자의 권한과 스페이스 멤버십을 다시 프로비저닝해야 합니다. 한 번만 선택하십시오.

PHI 지식 베이스를 생성 시점에 ACL 인식으로 만드십시오. 지원되는 소스(Amazon S3, Google Drive, SharePoint, Confluence Cloud, OneDrive)의 경우, 지식 베이스가 문서 수준 ACL을 적용할지 여부를 생성 시점에 결정합니다. 이 설정은 영구적입니다. ACL 없이 생성된 지식 베이스에는 ACL을 활성화할 수 없습니다. PHI와 관련된 모든 항목은 처음부터 ACL 인식 상태로 생성하십시오.

경고: 잘못 구성된 사용자 스토어 매핑은 오류나 경고 없이 제한된 문서를 잘못된 사용자에게 조용히 노출시킬 수 있습니다. PHI 콘텐츠를 수집하기 전에 신원-ACL 매핑을 검증하는 것이 매우 중요합니다.

AWS 리전, 네트워크 및 계정 경계

다음 요소를 기반으로 배포 리전을 계획하십시오:

• 데이터 레지던시: Amazon Quick는 프로비저닝된 리전에서 데이터를 처리하고 저장하며, 해당 리전이 조직의 데이터 현지화 요구 사항을 충족하는지 확인해야 합니다. Amazon Quick는 단일 리전 서비스입니다. 리전 내에서의 multi-AZ 복원력 은(는) 가지지만, 리전 간 페일오버는 지원하지 않습니다. 리전 간 복원력이 필요한 비즈니스 크리티컬 워크플로를 지원하는 경우, 두 번째 리전에 별도의 Amazon Quick 배포와 그 지원 데이터를 프로비저닝하십시오. 예를 들어, S3 기반 지식 베이스 소스를 여러 리전에 복제하는 것입니다.
• 서비스 가용성. 기능은 때때로 서로 다른 리전에 서로 다른 시기에 출시됩니다. 지식 베이스, 커넥터, Amazon Quick Sight 기능 등 에이전트에 필요한 모든 것이 배포하려는 위치에서 사용 가능한지 확인하십시오.
• 멀티 계정 전략. AWS Organizations의 전용 워크로드 계정에 Amazon Quick를 배치하십시오. Service Control Policy(SCP)를 사용하여 리전 제한을 강제하고 범위 밖 리전에서의 우발적인 프로비저닝을 차단하십시오.

네트워크 경계의 경우: Amazon Quick는 HTTPS를 통해 액세스하는 관리형 서비스입니다. 가상 프라이빗 클라우드(VPC)에 배포하지 않습니다. 그러나 데이터 소스(S3 버킷, 데이터베이스, 온프레미스 시스템)는 VPC 경계 뒤에 있을 수 있습니다. 가능한 곳에서는 VPC 엔드포인트와 AWS PrivateLink를 사용하십시오. DNS 확인 및 방화벽 규칙이 Amazon Quick의 커넥터가 네트워크를 필요 이상으로 개방하지 않고도 승인된 데이터 소스에 도달할 수 있도록 하십시오.

에이전트의 공격 표면 최소화

Amazon Quick의 자체 문서는 적대적 위험을 두 가지 조건의 문제로 규정합니다. (1) 에이전트가 신뢰 경계 외부의 콘텐츠를 읽을 수 있고, 그리고 (2) 중대한 조치를 취할 수 있을 때 위험이 존재합니다. 두 조건 중 하나라도 좁히면 노출을 줄일 수 있습니다.

에이전트가 읽을 수 있는 것을 제한합니다(Perceive 계층). 에이전트의 컨텍스트에 공급되는 모든 소스를 파악하십시오: 지식 베이스, 업로드된 파일, 웹 검색, 서드파티 리서치 제공업체, 커넥터 응답, MCP 도구 출력, 보존된 대화 메모리. PHI 워크플로의 경우:

• 에이전트를 신뢰할 수 있는 ACL 인식 지식 베이스로 범위를 한정합니다.
• 불필요한 곳에서는 오픈 웹 검색을 끕니다.
• 에이전트에 필요하지 않다면 파일 업로드를 끕니다.
• 대화 기록 보존을 최소한의 유용한 기간으로 제한합니다.

에이전트가 할 수 있는 것을 제한합니다(Act 계층). 모든 아웃바운드 경로를 목록화합니다: 커넥터, MCP 도구, 웹 쿼리, Quick Flows, Quick Automate 워크플로, 예약된 에이전트 실행. PHI 인접 에이전트의 경우:

• 읽기 전용 커넥터 액세스를 선호합니다.
• 자동화된 워크플로와 예약된 워크플로는 아무도 지켜보지 않는 상태에서 실행되므로 주의하십시오.
• 보안 팀이 명시적으로 정당화하고 승인한 경우가 아니라면 쓰기 작업을 차단합니다.
• 커넥터 수준 권한 범위 지정을 사용하여 에이전트가 호출할 수 있는 작업을 제한합니다.

작업이 실행되는 신원을 파악합니다. 온디맨드 작업은 호출하는 사용자로 인증되며, 해당 사용자의 커넥터 권한에 따라 제한됩니다. 자동화된 워크플로는 대화형 세션 없이 실행됩니다. 자율성 수준을 작업의 민감도에 맞추고, 어떤 에이전트가 어떤 신원 모드로 작동하는지 문서화하십시오.

최소 권한 원칙과 데이터 분리를 적용합니다

• PHI를 포함하는 지식 베이스와 스페이스를 일반 생산성용 것들과 분리합니다. 멤버십을 제한합니다.
• 스페이스 접근 권한과 에이전트 접근 권한을 need-to-know(필요한 사람만 알도록) 원칙에 따라 부여하세요. 공유 권한(누가 지식 베이스를 사용할 수 있는지)과 소스 문서 ACL(승인된 사용자가 실제로 검색할 수 있는 색인된 문서가 무엇인지)을 모두 점검하세요.
• 지식 베이스의 기본 새로 고침 주기는 24시간입니다. 접근 변경 사항을 더 빠르게 반영해야 한다면 주기를 단축하세요. 이메일 주소를 재할당하거나 재사용하기 전에 ACL을 새로 고침하세요.
• PHI 에이전트는 범용 생산성 도구와 스페이스를 공유해서는 안 됩니다. 즉, 사용 사례를 스페이스 수준에서 분리해야 합니다.
• 커넥터 권한을 정기적으로 점검하세요. AWS Secrets Manager에 저장된 자격 증명은 자격 증명 관리 정책에 맞는 일정에 따라 교체하세요.

데이터 최소화 실천

AWS는 청구 또는 진단 로그에 실수로 노출되는 일을 피하기 위해 리소스 이름이나 태그에 기밀 데이터를 입력하지 말 것을 권장합니다.

• 사용 사례가 허용하는 곳에서는 가능한 한 비식별화된 데이터를 사용하세요.
• 데이터베이스나 API에서 구조화된 데이터를 수집할 때는 색인화하기 전에 소스 단계에서 열과 행을 필터링하세요.
• 에이전트 가드레일을 구성하여 응답에서 PII를 마스킹 처리하세요. 내장된 PII 탐지 필터를 사용해 주민등록번호 같은 Social Security 번호(SSN), 의료 기록 번호(MRN), 생년월일을 숨기세요.

감사 로깅 및 보존 구성

Amazon Quick는 여러 가지 고유한 감사 신호를 제공합니다. 이 중 어떤 것도 기본적으로 전달되지 않으므로 직접 활성화해야 할 수 있습니다.

설정 방법은 다음과 같습니다:

1. 대상 계정과 리전에 대해 CloudTrail 트레일을 생성합니다.
2. Amazon Quick의 AI 기능을 켠 직후 CloudWatch vended log delivery(CHAT_LOGS, FEEDBACK_LOGS, KB_FILE_SYNC_LOGS)를 구성합니다.
3. 채팅 로그에 CloudWatch Logs 데이터 보호 마스킹을 적용하여 PHI가 평문으로 저장되지 않도록 합니다.
4. 최소 6년의 보존 기간을 설정합니다. 로그 아카이브에 S3 Object Lock 사용을 고려합니다.
5. 비정상 활동에 대한 CloudWatch 알람을 추가합니다.
6. 지속적인 규정 준수 검사를 위해 AWS Security Hub를 활성화합니다.
7. 중요 알림을 보안 정보 및 이벤트 관리(SIEM) 또는 사고 대응 플랫폼으로 라우팅합니다.

확장하기 전에 검증하세요

범위를 확장하기 전에 다음 사항을 확인하십시오:

• BAA 수락이 규정 준수 등록부에 기록되어 있습니다.
• 데이터 분류가 문서화되어 있습니다: 어떤 지식 베이스와 스페이스에 PHI가 포함되어 있는지, 어떤 에이전트가 이에 접근할 수 있는지.
• 적대적 쿼리와 프롬프트 인젝션 시나리오가 테스트되었습니다.
• 로그가 수집되고 있으며 마스킹이 올바르게 작동합니다.
• 테이블톱 침해 대응 훈련이 완료되었습니다.
• InfoSec의 승인을 받았습니다.

알려진 제한 사항

다음은 Amazon Quick의 몇 가지 알려진 제한 사항입니다.

• Free 또는 Plus 경로에서는 BAA를 제공하지 않습니다. BAA 적용을 받으려면 AWS Management Console을 통해 프로비저닝된 경로를 사용해야 합니다.
• 교차 리전 복제를 지원하지 않습니다. 재해 복구(DR)는 단일 리전으로 제한됩니다.
• 가드레일은 확률적이며 결정론적이지 않습니다. 가드레일은 위험을 줄여줍니다. 위험을 없애지는 않습니다. 앞서 설명한 인프라 수준의 컨트롤로 보완하십시오.
• 서드파티 커넥터는 BAA 의무를 확장합니다. 커넥터가 외부 시스템으로 데이터를 전송할 때, 규정 준수 책임은 데이터를 따라갑니다.
• 대화 메모리에 반출된 PHI가 포함될 수 있습니다. 보존 정책을 설정하고 마스킹을 적용하십시오.

구현 가이드

AnyCompany Health Plan 예제는 Amazon Quick을 롤아웃하는 방법을 보여주었습니다. 이 섹션에서는 해당 패턴을 플랫폼 팀에 전달할 수 있는 단계별 프로젝트 계획으로 전환합니다.

1단계: BAA 체결 (1일차)

• AWS Artifact 권한으로 로그인하고 BAA에 동의합니다.
• 계약 ID, 타임스탬프, 보안 주체 ARN, 계정 ID를 기록합니다.
• 법무 및 컴플라이언스 팀에 알립니다.

2단계: 기반을 다지는 되돌릴 수 없는 통제 설정 (1–2일차)

• 고객 관리형 키를 계정 기본값으로 등록합니다.
• 키 정책에 필수 권한인 Encrypt, Decrypt, GenerateDataKey, DescribeKey가 부여되어 있는지 확인합니다.
• 자격 증명 모델을 구성합니다(IAM Identity Center가 권장됩니다).
• 해당 계정이 리전 제한 SCP가 적용된 전용 워크로드 조직 단위(OU)에 속해 있는지 확인합니다.

3단계: ACL 인식형 지식 베이스 생성 (3~7일차)

• 데이터 소스를 PHI, PHI 인접, 비 PHI로 분류합니다.
• PHI 및 PHI 인접 소스에 대해 ACL 인식을 켠 상태로 지식 베이스를 생성합니다.
• 자격 증명 스토어를 소스 권한에 매핑하고 여러 테스트 사용자로 검증합니다.
• 동기화 로그에서 성공적인 수집이 확인되는지 검증합니다. PHI 지식 베이스는 일반 콘텐츠와 분리해 유지합니다.

4단계: 스페이스 생성 (5~8일차)

• PHI 인접 스페이스를 일반 생산성 스페이스와 분리합니다.
• 지식 베이스, 대시보드, 액션 커넥터를 연결합니다. 멤버십을 제한합니다.
• 권한 없는 사용자가 차단되는지 확인합니다.

5단계: 가드레일을 갖춘 사용자 지정 에이전트 생성 (7~12일차)

• 각 에이전트의 목적을 좁게 정의합니다. 필요한 지식 소스만 연결합니다.
• PII 마스킹, 차단 주제, 콘텐츠 필터, 그라운딩 제어를 구성합니다.
• 일반 쿼리, 경계 쿼리, 적대적 프롬프트로 테스트합니다.
• 결과와 시정 조치 단계를 문서화합니다.

6단계: 액션 커넥터 구성 (10~14일차)

• PHI 인접 데이터에 대해 읽기 전용 모드로 시작합니다. 각 커넥터를 특정 리소스로 범위를 한정합니다.
• 자격 증명은 교체(로테이션)를 켠 상태로 AWS Secrets Manager에 저장합니다.
• 쓰기 액세스에 대한 정당성을 문서화합니다. 켜기 전에 보안 팀의 승인을 받습니다.
• 범위 제한을 테스트하여 커넥터가 의도된 범위를 넘어선 리소스에 도달할 수 없음을 확인합니다.

7단계: 감사, 보존, 모니터링 구성 (12~16일차)

• CloudTrail 및 CloudWatch vended 로그를 활성화합니다.
• 데이터 보호 마스킹을 적용합니다. 보존 기간을 최소 6년으로 설정합니다. S3 Object Lock을 활성화합니다.
• 알람을 구성하고, Security Hub를 활성화하며, SIEM과 통합합니다.

8단계: InfoSec 검증 (14~21일차)

• 증거 패키지를 취합합니다: BAA 확인, KMS 구성, 자격 증명 설정, 데이터 분류, 테스트 결과, 로그 샘플.
• 테이블톱 침해 대응 훈련을 실시합니다.
• InfoSec 팀에 보고합니다. 발견 사항을 시정합니다. 승인을 받습니다.

확장 단계 (4~8주차)

비 PHI 워크플로로 시작합니다: 정책 Q&A, 문서 검색, 회의 준비, 워크플로 자동화. 이를 통해 PHI가 도입되기 전에 팀이 플랫폼에 대한 자신감을 쌓을 수 있습니다.

그런 다음 PHI 인접 워크플로로 확장합니다: 임상 문서화 지원, 클레임 처리, 사전 승인, 규제 Q&A, 담당자 검토를 거치는 환자 커뮤니케이션 초안 작성.

면밀히 모니터링하십시오: 채팅 로그를 매주 검토하고, 가드레일 트리거율을 추적하며, 각 새 워크플로가 운영된 후 30일 동안 액세스 패턴을 관찰하십시오.

결론

Amazon Quick는 규제 대상 의료기관과 이들을 지원하는 사업자(business associate)에게 에이전틱 AI, 지식 검색, 비즈니스 인텔리전스, 자동화, 연구 등 전체 기능 범위에서 HIPAA 적격인 관리형 AI 작업 공간을 제공합니다.

규정을 준수하는 배포를 위한 경로는 명확한 순서를 따릅니다:

1. 적격(eligible)과 준수(compliant)의 차이를 이해하고, 공동 책임에서 귀사의 몫을 소유하십시오.
2. AWS Management Console을 통해 프로비저닝된 계정에서 BAA를 체결하십시오.
3. 되돌릴 수 없는 제어를 먼저 설정하십시오: KMS 키, 신원 모델, ACL 인식 지식 베이스.
4. 에이전트의 읽기 및 작업 범위를 최소화하고, 최소 권한 원칙을 강제하며, 로그에서 PHI를 마스킹하십시오.
5. InfoSec 팀과 함께 검증한 후, 비-PHI 워크플로에서 PHI 인접 워크플로로 확장하십시오.

규정 준수 기대치는 기술만큼 빠르게 변화하고 있습니다. AWS는 2026년 4월에 에이전틱 AI를 위한 4가지 보안 원칙 을 발표했고 2026년 6월에는 Well-Architected Agentic AI Lens 2026년 6월에. 오늘 결정론적이고 인프라 수준의 제어를 기반으로 구축하는 조직은 규제 기대치가 에이전틱 AI의 기능을 따라잡을 때 유리한 위치에 있을 가능성이 높습니다.

다음 단계

Amazon Quick를 평가 중이라면: AWS 계정 팀에 규정 준수 중심 브리핑을 요청하십시오. BAA 범위, 에이전틱 AI에 대한 공동 책임, 최신 HIPAA 적격 서비스 추가 사항에 대해 문의하십시오.

배포할 준비가 되었다면: 구현 가이드를 프로젝트 계획으로 사용하십시오. 2단계의 되돌릴 수 없는 결정들은 리소스 생성을 시작하기 전에 별도의 아키텍처 검토가 필요합니다.

이미 Amazon Quick를 운영 중이라면: 이 게시물의 모범 사례, 특히 에이전틱 보안 원칙과 알려진 제한 사항 목록을 기준으로 배포를 감사하십시오.

아키텍처 지침이 필요하면 AWS Solutions Architect 또는 AWS Healthcare and Life Sciences 팀에 문의하십시오.

저자 소개