AWS에서 AI 에이전트 거버넌스 구현하기 — 실행 차단과 EU AI Act 증거 기록

AI 요약

작성자는 Amazon Bedrock의 Nova Pro와 Strands Agents로 합성 대출 심사 시스템을 구성하고 Traccia를 연결해 에이전트 거버넌스를 시험합니다. 관찰 가능성(Observability)이 에이전트의 실행과 비용을 기록한다면, 거버넌스는 잘못된 실행을 막고 사후 감사에 필요한 기록을 남기는 역할을 합니다. 특히 다중 에이전트에서는 전체 작업을 멈추는 차단, 모든 하위 에이전트 추적에 걸친 개인정보 마스킹, 실제로 비용을 쓰는 에이전트에 맞춘 정책 설정이 필요합니다.

구성과 로컬 가드레일

대출 심사 크루는 감독자 에이전트가 신청 정보 처리(Intake), 신용·위험 평가(Credit & Risk), 대출 정책 판단(Policy)을 맡은 세 에이전트에 작업을 나누는 구조입니다. 신용 점수는 실제 신용평가가 아닌 결정론적 모의 점수이며, 실제 신청자나 실제 대출 결정도 사용하지 않습니다. 작성자는 보호 속성이 점수에 들어가지 않는지 테스트로 확인했다고 설명합니다.

Traccia의 로컬 SDK 기능은 계정 키 없이 실행됩니다. 프롬프트 인젝션 탐지 결과를 받은 작성자의 코드가 예외를 발생시켜 크루를 중단하고, 내보내기 전에 이메일·전화번호·SSN을 정규식으로 마스킹합니다. 차단된 추적에는 루트와 인젝션 검사 스팬만 남고 하위 에이전트 스팬은 없으며, 테스트 개인정보도 전체 스팬에서 발견되지 않았다고 보고합니다. 다만 가드레일 엔진 자체는 탐지 결과를 기록할 뿐 실행을 막지 않습니다. 실제 차단은 결과를 확인한 애플리케이션 코드가 수행합니다. 정규식 마스킹은 이름이나 주소를 놓칠 수 있고 과도하게 가릴 수도 있어, 작성자는 이를 ML 기반 개인정보 탐지와 구별해야 한다고 강조합니다.

규제 정보도 스팬에 기록합니다. SDK 설정으로 모든 스팬에 고위험 등급을 표시하고, EU AI Act 부속서 III의 신용도 평가 분류인 5(b)는 작성자가 별도 속성으로 추가합니다. Article 50 투명성 정보와 무결성 해시도 기록합니다. 가드레일 탐지 단계 중 명시적 검사인 A와 오류 메시지 기반 휴리스틱인 C는 시연하지만, 모델 자체의 안전 신호에 의존하는 B는 정상 실행에서 발동하지 않습니다.

정책 차단이 처음에는 작동하지 않은 이유

플랫폼의 런타임 정책은 SDK의 로컬 기능과 별도입니다. Traccia 키와 추적 엔드포인트가 필요하며, 엔드포인트를 설정하지 않으면 SDK가 경고를 남기고도 실행을 허용합니다. 작성자는 처음에 엔드포인트를 빠뜨려 정책 평가가 건너뛰어지는 일을 겪었습니다.

엔드포인트를 설정한 뒤에도 Model Boundary 정책은 적용되지 않았습니다. 허용 모델을 GPT-4o로 제한했지만, 크루가 사용하는 Strands BedrockModel 호출은 Traccia가 자동으로 패치하는 LLM 클라이언트가 아니었습니다. 정책을 크루 진입점인 loan-prescreen에 적용한 것도 문제였습니다. Strands의 run_identity에 따라 개별 도구 호출은 실제 호출자인 하위 에이전트 credit-risk의 이름으로 평가됐기 때문입니다. 따라서 정책 범위를 호출 에이전트에 맞춰야 합니다.

Spend Cap도 credit-risk에 적용하고 예산을 0달러로 설정했지만 발동하지 않았습니다. 해당 크루의 두 도구 호출 비용이 사실상 0에 가까워 지출 제한을 넘지 않았기 때문입니다. 세 정책 가운데 실제로 크루에서 관측되는 신호와 맞아 작동한 것은 Loop Cap이었습니다. 최대 도구 호출 수를 1회로 설정하고 credit-risk에 적용하자, 도구 호출 2회가 한도를 넘었다는 사유와 실행마다 새로 발급되는 decision ID를 담은 AgentBlockedError가 발생했습니다. 작성자는 이처럼 실제 사유와 ID가 포함된 오류가 호출 단위 정책 차단의 증거라고 설명합니다.

감사 기록과 한계

차단된 실행 하나를 바탕으로 시스템을 고위험 AI 시스템으로 등록하고, 사람 검토를 요청하고, 사고를 기록한 뒤 감사 번들을 내보냈습니다. 번들은 등록 정보, 정책 결정, 검토 요청, 사고 기록과 관리자 감사 이벤트를 담은 약 10KB의 JSON 파일입니다. 작성자가 확인한 항목에는 연결된 에이전트 3개, 검토 요청 1건, 사고 1건, 감사 이벤트 110건, 최상위 무결성 해시가 포함됩니다. EU AI Act 모듈을 켜면 기본권 영향평가(FRIA) 초안, 사용 지침, Annex IV 기술 문서 개요, EU 등록 사전 입력 자료도 생성됩니다.

다만 이런 자료는 규제 증거의 기반이지 법적 준수 판정이 아닙니다. 실제 적합성 판단에는 별도의 법률 검토나 적합성 평가가 필요합니다. 해시는 비밀키 없는 SHA-256이므로 전자 서명이 아니라 변조 흔적을 확인하는 수준입니다. EU 등록 자료도 공식 등록이 아니라 사전 입력본이라고 표시합니다. 또한 @govern은 기본적으로 장애 시 허용하는 fail-open 설정이며, fail_open=False를 지정해도 호출별 정책 검사는 항상 fail-open으로 동작한다고 작성자는 설명합니다. 네트워크가 실행 중 끊기면 개별 호출이 통과할 수 있습니다.

작성자는 EU AI Act상 신용평가 고위험 의무가 2027년 12월 2일부터 적용된다고 적고, Article 50 투명성 의무는 2026년 8월 2일부터 시행된다고 안내합니다. 정책 대시보드의 ‘Open Violations’가 차단 직후 0으로 보이는 현상도 설명합니다. Loop Cap 같은 예방 정책은 Decision Log에 즉시 ‘Denied’로 나타나지만, 사후 감시 정책은 주기적으로 평가되며 가장 짧은 주기도 시간 단위라 위반 항목이 나중에 표시됩니다.

글의 실무적 요점은 관찰과 차단을 서로 다른 계층으로 다루고, 다중 에이전트 정책을 실제 호출 주체와 스팬에 기록된 신호에 맞추라는 것입니다. 작성자는 Decision Log의 ‘No Match’와 ‘Denied’ 기록으로 정책 미적용 원인을 찾았다고 합니다. 또한 플랫폼 엔드포인트 누락, 하위 에이전트 정체성에 따른 정책 범위, 호출별 fail-open 동작은 설정과 문서에서 더 명확히 드러나야 한다고 지적합니다.

dev.to 반응

• @steven_r_404 — AI 에이전트 거버넌스, 런타임 실행 제어, 감사 증거를 결합한 점이 AWS 클라우드에서 프로덕션 AI 시스템을 만드는 팀에 특히 유용합니다.
  • @sarvar_04 — 네, AWS에서 프로덕션 AI 시스템을 만드는 데 분명 도움이 될 것입니다.
• @sarvar_04 — AWS Strands 다중 에이전트 거버넌스 설정, 런타임 차단, EU AI Act 증거 흐름을 직접 시연합니다. 프로덕션 환경의 AI 에이전트 거버넌스에 관한 의견을 듣고 싶습니다.

원문: dev.to / 번역·요약: Trawling