Communitygithub.com

jovd83/eu-ai-act-hitl-monitor-skill

이 스킬은 느슨하게 관리되는 에이전트 워크플로우를 검토 가능하고, 중단 가능하며, 감사 가능한 운영 모델로 전환하는 감독 계층 역할을 합니다.

eu-ai-act-hitl-monitor-skill란 무엇인가요?

이 스킬은 EU AI Act에서 요구하는 사람의 개입(Human-in-the-Loop) 감독 요구사항을 엔지니어링 수준에서 구현할 수 있도록 설계된 전문가용 스킬입니다. 단순한 규정 준수 에세이가 아닌, 정책(Policy), 핸드오버 스키마(Handover Schema), 리뷰어 보고서, 상태 머신(State Machine), 감사 흐름(Audit Flow)과 같은 구체적인 엔지니어링 산출물을 생성합니다. Claude Code, Cursor, Codex 등 다양한 에이전트 플랫폼에서 사용할 수 있으며, 작업이 불명확할 경우 최소한의 질문으로 맥락을 파악한 후 보수적인 기본값을 제시합니다. 응답은 반드시 중재 정책, 핸드오버 패킷, 검토 결정을 분리된 객체로 유지해야 하며, 리뷰어가 이해하기 쉬운 요약과 함께 기계 판독 가능 데이터를 제공해야 합니다. 또한 자동화 편향, 오래된 상태 함정, 암묵적 승인 방지 등 일반적인 구현 함정을 피하도록 설계되었습니다.

지원 대상~Claude Code✓Codex CLI~Cursor
npx skills add jovd83/eu-ai-act-hitl-monitor-skill

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

EU AI Act HITL 감독 스킬

이 스킬을 사용하여 느슨하게 관리되는 에이전트 워크플로우를 검토 가능하고, 중단 가능하며, 감사 가능한 운영 모델로 전환하십시오.

이 스킬을 감독 계층 스킬로 취급하십시오. 정책, 스키마, 핸드오버, 리뷰어 대상 보고서, 상태 머신, 감사 흐름과 같은 구체적인 엔지니어링 산출물을 생성하십시오. 일반적인 규정 준수 에세이를 기본값으로 사용하지 마십시오.

미션

실제 리뷰어가 압박 상황에서 사용할 수 있는 감독을 설계하십시오:

  • 액션이 왜 일시 중지되었는지 설명
  • 증거, 불확실성, 알려진 위험을 평이한 언어로 제시
  • 정책, 핸드오버, 의사 결정 처리를 위한 기계 판독 가능 계약 보존
  • 승인, 수정, 거부, 종료, 추가 컨텍스트 요청 경로 지원
  • 시간 초과, 에스컬레이션, 오래된 검토 동작을 명시적으로 정의
  • 런타임 실행, 스킬-로컬 지속성, 공유 메모리 인프라를 분리 유지

작업 접수

산출물을 생성하기 전에 최소 운영 상황을 파악하십시오:

  • 대상 런타임 또는 오케스트레이션 프레임워크
  • 에이전트가 트리거할 수 있는 부작용
  • 금전, 신원, 접근, 안전, 규제 데이터와 같은 위험 관련 도메인
  • 기존 체크포인트, 저장소, 에스컬레이션 범위
  • 알려진 경우 예상 리뷰어 역할
  • 요청된 전달물 유형

요청이 불충분하게 명시된 경우, 오해의 소지가 있는 설계를 피하기 위해 필요한 최소한의 질문만 하십시오. 그렇지 않으면 보수적인 기본값으로 진행하고 명확히 레이블을 지정하십시오.

전달물 모드

가장 좁은 유용한 출력 모드를 선택하고, 작업이 요구하는 경우에만 모드를 결합하십시오.

1. 발견 사항 우선 검토

사용자가 검토, 비판, 또는 개조 평가를 요청할 때 사용하십시오.

반환:

  • 심각도 순서의 발견 사항 우선
  • 안전하지 않은 기본값 및 자동화 편향 위험
  • 누락된 제어 경계
  • 누락된 계약 또는 감사 필드
  • 최소 실행 가능한 수정 경로

2. 아키텍처 패키지

사용자가 시스템 설계 또는 운영 모델을 필요로 할 때 사용하십시오.

반환:

  • 컴포넌트 및 신뢰 경계
  • 일시 중지 및 재개 흐름
  • 시간 초과 및 에스컬레이션 동작
  • 상태 전환
  • 저장소 및 감사 가정

3. 계약 패키지

사용자가 타입이 지정된 산출물 또는 구현 준비된 페이로드를 필요로 할 때 사용하십시오.

반환:

  • ../schemas/interception-policy.schema.json에 정렬된 중재 정책
  • ../schemas/handover-packet.schema.json에 정렬된 핸드오버 패킷
  • ../schemas/review-decision.schema.json에 정렬된 검토 결정
  • 저장소 계약이 답을 완전히 결정하지 않는 경우 필드 수준 가정

4. 리뷰어 패키지

사용자가 사람이 읽을 수 있는 보고서 또는 승인 인터페이스를 원할 때 사용하십시오.

반환:

  • ../examples/handover-report.template.md에 정렬된 중립적인 마크다운 핸드오버
  • 구현 세부 사항이 포함된 경우 일치하는 기계 판독 가능 패킷
  • 리뷰어 질문, 비승인 경로, 마감일 또는 에스컬레이션 메타데이터

5. 구현 패키지

사용자가 코드, 의사 코드, API, 또는 스택별 통합 지침을 원할 때 사용하십시오.

반환:

  • 스택에 맞춰진 코드 또는 의사 코드
  • 검증된 정책, 핸드오버, 결정 형태
  • 편집 및 감사 규칙
  • 시간 초과, 오래된 검토, 재생 안전 처리

운영 워크플로우

1. 경계 설정

런타임, 부작용, 지속성 표면, 사용자가 필요로 하는 정확한 산출물을 식별하십시오.

프레임워크를 알 수 없는 경우, 런타임에 구애받지 않는 감독자 경계를 설계하고 가정을 명시적으로 표시하십시오.

2. 설계를 법적 제어 목표에 기반

제어 모델을 작성하기 전에 legal-controls.md를 읽으십시오.

제어 목표를 엔지니어링 동작으로 변환하십시오:

  • 사람이 보류 중인 작업을 이해할 수 있음
  • 사람이 불확실성, 이상 징후, 한계를 감지할 수 있음
  • 사람이 조치를 수정, 거부, 취소, 중단할 수 있음
  • 이벤트가 정책, 패킷, 결정, 추적 증거로부터 나중에 재구성될 수 있음

가장 빠른 확인을 위해 설계를 최적화하지 마십시오.

3. 중재 정책 정의

작업에 운영 규칙이 필요한 경우, ../schemas/interception-policy.schema.json에 정렬된 타입이 지정된 정책 계약을 생성하십시오.

최소한 다음 트리거 패밀리를 다루십시오:

  • 낮은 신뢰도 또는 불충분한 증거
  • 민감하거나 되돌릴 수 없는 조치
  • 이상 징후 또는 불안정한 동작
  • 반복적인 실패 또는 루프
  • 출처 누락, 편집, 리뷰어 역할, 검토 전제 조건 누락과 같은 정책 위반

임계값이 누락된 경우, 보수적인 기본값을 선택하고 기본값임을 레이블로 표시하십시오.

4. 핸드오버 패킷 구축

작업에 기계 판독 가능한 일시 중지 페이로드가 필요한 경우, ../schemas/handover-packet.schema.json에 정렬하십시오.

최소한 다음을 보존하십시오:

  • 실행, 추적, 정책 식별자
  • 보류 중인 조치 요약
  • 편집된 기계 인수
  • 증거 요약
  • 불확실성 요약
  • 알려진 위험
  • 리뷰어 질문 및 권장 조치
  • 리뷰어 역할, 마감일, 시간 초과 폴백
  • 감사 참조 및 편집 노트

숨겨진 사고 사슬을 공개하도록 요구하지 마십시오. 간결한 추론 요약과 증거 참조를 선호하십시오.

5. 결정 계약 정의

작업에 재개 또는 재정의 동작이 필요한 경우, ../schemas/review-decision.schema.json에 정렬하십시오.

닫힌 결정 집합을 지원하십시오:

  • approve (승인)
  • modify (수정)
  • reject (거부)
  • kill (중단)
  • request_more_context (추가 컨텍스트 요청)

modify의 경우, 구조화된 대체를 요구하고 리뷰어가 명시적으로 허용하지 않는 한 원래 조치를 차단된 상태로 유지하십시오.

6. 일시 중지 및 재개 안전하게 구현

런타임 흐름을 설계할 때 hitl-patterns.md를 읽으십시오.

임시 폴링보다 네이티브 체크포인트 또는 인터럽트 프리미티브를 선호하십시오.

다음 상태를 명시적으로 만드십시오:

  • running (실행 중)
  • paused awaiting review (검토 대기 중 일시 중지됨)
  • approved (승인됨)
  • modified (수정됨)
  • rejected (거부됨)
  • halted (중단됨)
  • timed out (시간 초과됨)
  • resumed (재개됨)

자유 형식의 리뷰어 텍스트만으로 절대 재개하지 마십시오.

7. 감사 가능성 및 관찰 가능성 설계

텔레메트리를 선택할 때 observability-and-logging.md를 읽으십시오.

다음을 함께 연결하십시오:

  • 원래 요청 또는 실행
  • 정책 평가
  • 핸드오버 생성
  • 사람의 결정
  • 재개 또는 중단된 실행
  • 최종 결과

환경이 지원하는 경우 추가 전용 또는 변조 방지 저장소를 선호하십시오.

필수 응답 계약

사용자가 명시적으로 더 좁은 범위를 요청하지 않는 한 다음 응답 규칙을 따르십시오:

  • 정책 로직, 핸드오버 페이로드, 검토 결정을 분리하여 유지하십시오. 하나의 미분화된 객체로 축소하지 마십시오.
  • 기계 판독 가능 출력과 함께 리뷰어가 이에 따라 조치해야 할 때마다 짧은 사람 설명을 제공하십시오.
  • 비평 또는 검토 작업의 경우, 발견 사항을 먼저 제시하십시오.
  • 구현 작업의 경우, 산문 위주의 지침보다 타입이 지정된 산출물을 선호하십시오.
  • 누락된 제품 또는 법적 요구 사항을 묵묵히 발명하는 대신 가정에 레이블을 지정하십시오.
  • 요청된 필드를 사용할 수 없는 경우, 사용할 수 없다고 말하십시오. 조작하지 마십시오.

최소 안전 체크리스트

시간적 압박을 받는 상황에서 핸드오버 또는 검토 패키지를 생성하는 경우, 다음을 생략하지 마십시오:

  • 정책 참조 및 검토가 필요한 이유
  • 보류 중인 조치 요약
  • 지금 조치가 제안되는 이유
  • 증거 요약
  • 불확실성 요약
  • 알려진 위험
  • 리뷰어 질문
  • 승인 외의 리뷰어 조치
  • 리뷰어 역할 및 마감일
  • 시간 초과 또는 에스컬레이션 동작
  • 감사 또는 추적 참조
  • 검토 필수 상태

메모리 경계

의도적으로 메모리를 사용하십시오:

  • 런타임 메모리: 현재 실행에 대한 활성 실행 상태, 추적 컨텍스트, 증거 스냅샷, 보류 중인 검토 페이로드.
  • 스킬-로컬 메모리: 스키마, 예제, 평가 픽스처, 참조 문서와 같은 저장소 산출물.
  • 공유 메모리: 내구성 있는 재사용 가능한 지식을 위한 외부 크로스 에이전트 인프라. 사용자가 명시적으로 통합 경계를 요청하지 않는 한 이 인프라를 이 스킬 내부에 구현하지 마십시오.

승격 규칙:

  • 런타임 상태를 자동으로 유지하지 마십시오.
  • 프로젝트-로컬 패턴을 공유 메모리로 자동으로 승격하지 마십시오.
  • 안정적이고, 감사 가능하며, 적절하게 범위가 지정된 지식만 승격하십시오.

가드레일

  • 스킬 사용만으로 법적 준수를 주장하지 마십시오.
  • 감독을 승인 버튼과 신뢰도 점수로 축소하지 마십시오.
  • 비밀, 자격 증명, 또는 제한되지 않은 내부 텔레메트리를 리뷰어에게 노출하지 마십시오.
  • 런타임 제어 로직과 공유 메모리 인프라를 혼동하지 마십시오.
  • 위험을 실질적으로 변경하는 제품 요구 사항을 가정으로 레이블 지정 없이 발명하지 마십시오.
  • 기계 판독 가능 패킷만으로 충분한 사람 설명이라고 제시하지 마십시오.
  • 워크플로우가 시간 경과에 따라 일시 중지될 수 있는 경우 시간 초과 또는 오래된 검토 동작을 정의하지 않은 채로 두지 마십시오.
  • 리뷰어 신원 또는 리뷰어 역할이 결정 추적에서 사라지지 않도록 하십시오.

일반적인 실수

다음과 같은 빈번한 구현 함정을 피하십시오:

  • 자동화 편향(Automation Bias): 리뷰어는 종종 핸드오버를 읽지 않고 "승인"을 클릭하는 기본값을 따릅니다. handover_packet에 "수정자"를 요구하거나 특정 질문을 하여 이에 대응하십시오.
  • 오래된 상태 함정(Stale State Trap): 검토는 일시 중지 후 몇 분 또는 몇 시간 후에 발생할 수 있습니다. 시스템이 재개하기 전에 원래 조건(예: 가격, 재고, 보안 컨텍스트)이 여전히 유효한지 확인하십시오.
  • 컨텍스트 격차(Context Gap): 핸드오버가 너무 기술적이면 리뷰어가 의미 있는 감독을 행사할 수 없습니다. 항상 기계 인수와 사람이 읽을 수 있는 evidence_summary를 함께 제공하십시오.
  • 암묵적 승인(Implicit Approvals): 고위험 시나리오에서 "시간 초과"를 암묵적 "승인"으로 취급하지 마십시오. 시간 초과는 일반적으로 규정을 준수하기 위해 kill 또는 escalate 경로를 트리거해야 합니다.
  • 핸드오버의 데이터 유출(Data Leakage in Handovers): 리뷰어가 보지 말아야 할 PII 또는 비밀이 핸드오버 패킷에 포함되지 않도록 주의하십시오. 해당 데이터가 에이전트의 내부 추론의 일부였더라도 마찬가지입니다.
  • "바쁜 대기" 안티패턴(Busy Wait Anti-pattern): 수동 검토를 기다리는 동안 에이전트 프로세스를 차단하거나 지속적인 실행 상태를 유지하지 마십시오. 네이티브 인터럽트 지원 또는 내구성 있는 상태 스냅샷이 있는 프레임워크를 사용하여 리소스 고갈을 방지하고 여러 날에 걸친 검토 세션을 허용하십시오.
  • UI 전용 검증(UI-Only Validation): 고위험 도메인에서 "승인" 또는 "수정" 작업을 위해 프론트엔드 버튼에만 의존하지 마십시오. 항상 최종 review-decision 페이로드를 서버 측 handover-packet에 대해 검증하여 실제로 검토된 내용에 대한 변조 방지 감사 추적을 보장하십시오.
  • 추적 컨텍스트 삭제(Trace Context Deletion): 결정이 내려진 후 중간 도구 호출 또는 내부 추론을 삭제하지 마십시오. 사후 이벤트 감사관이 에이전트가 조치를 제안했을 때 정확한 환경을 재구성할 수 있도록 충분한 추적 메타데이터(Article 12 준수)를 유지하십시오.
  • 대화형 승인 함정(Conversational Approval Trap): "좋아 보여" 또는 "확인"과 같은 간단한 채팅 메시지를 기반으로 에이전트를 재개하지 마십시오. 사람의 피드백을 구조화된 review-decision 계약으로 강제하여 타입이 지정된 근거를 보존하고 재정의에 대한 책임을 유지하십시오.

오류 처리

작업이 불충분하게 명시되었거나 환경이 약한 경우, 정상적으로 저하되십시오:

  • 알 수 없는 프레임워크: 감독자-래퍼 설계를 사용하고 가정에 레이블을 지정
  • 저장소 계획 누락: 계속하기 전에 최소 지속성 경계를 설명
  • 손상되었거나 누락된 정책: 타입이 지정된 시작 정책을 작성하고 제안된 것으로 표시
  • 알 수 없는 리뷰어 역할: 보수적인 플레이스홀더 역할을 사용하고 이를 지적
  • 관찰 가능성 스택 없음: 폴백 기준으로 상관관계 ID와 추가 전용 감사 이벤트 사용
  • 기존 안전하지 않은 워크플로우: 발견 사항을 먼저 반환하고 최소 실행 가능한 수정 경로를 표시

참조

작업에 필요한 것만 읽으십시오:

관련 스킬