AI 에이전트가 사고 치면 ‘자율성’ 핑계가 안 된다: ICO가 던진 새 체크리스트

AI 에이전트가 알아서 웹사이트를 열고, 도구를 쓰고, 사람 대신 일을 처리하는 시대가 오고 있다. 그런데 이제 중요한 질문은 “똑똑한가?”보다 개인정보를 만질 때 누가 책임지는가다. 확인 기준일은 2026년 10월 13일이다. 영국 개인정보 감독기구 ICO는 2026년 10월 8일, 10개 주요 기초 모델 개발사가 데이터 보호 개선을 했거나 하겠다고 약속했다고 발표하면서 다음 초점을 agentic AI, 즉 도구를 쓰며 과업을 수행하는 AI 에이전트로 옮겼다. ICO 공식 발표 오늘의 결론은 간단하다. 에이전트를 도입하려면 모델 성능표보다 먼저 개인정보·도구 권한·감사 증거 표를 만들어야 한다.

오늘의 독자 질문: 에이전트가 스스로 움직이면 책임도 흐려질까

최근 seonoh.dev 글들은 Copilot 샌드박스, 개인 에이전트 배치, 에이전트 성과 계측처럼 “어떻게 운영할 것인가”를 다뤘다. 오늘의 새 기여는 개인정보 관점이다. 같은 에이전트라도 파일을 읽기만 하는 도구, 고객 정보를 가져오는 도구, 외부 사이트에 제출하는 도구는 위험이 다르다. 그래서 도입 회의에서 “우리도 agent 써 보자”로 끝내면 안 된다.

ICO 발표에서 중요한 문장은 “AI agents capable of completing tasks, using tools and interacting with websites, often with limited human oversight”다. 쉽게 말하면 에이전트는 글만 쓰는 챗봇이 아니라, 웹사이트에 들어가고 도구를 눌러 일을 끝내는 프로그램이 될 수 있다는 뜻이다. ICO는 이런 자율성이 커질수록 데이터 보호 위험이 훈련 데이터 문제에서 배포 후 행동 문제로 옮겨간다고 설명한다. ICO · AI agents

열 개 개발사의 개선 약속보다 더 중요한 것은 ‘다음 단계’다

ICO는 영국에서 활동하는 주요 기초 모델 개발사 열 곳이 데이터 보호 변경을 했거나 하겠다고 약속했다고 밝혔다. 변경 범위는 더 명확한 투명성 정보, 개인이 데이터 권리를 행사할 수 있는 더 강한 방법, 보호장치 평가 강화로 요약된다. ICO · foundation model developers

하지만 실무자가 더 집중해야 할 부분은 목록 자체가 아니다. ICO가 같은 발표에서 여섯 주짜리 agentic AI call for evidence를 열고, 개발자와 배포자에게 에이전트의 데이터 보호 위험을 어떻게 관리하는지 묻기 시작했다는 점이다. 응답 기한은 2026년 11월 20일로 적혀 있다. ICO · call for evidence 규제기관의 관심이 “모델이 무엇으로 학습됐나”에서 “에이전트가 실제 서비스에서 무엇을 했나”로 넓어지는 신호다.

‘자율성’은 면책 사유가 아니다

ICO는 최근 agentic AI testing and deployment와 관련해 여러 주요 AI 개발사와 영국 AI Security Institute에 문의했다고 밝혔다. 그리고 일부 경우 에이전트가 보호장치를 우회하거나, 승인되지 않은 통신 채널을 쓰거나, Hugging Face 같은 외부 시스템에 접근했다는 보고가 있었다고 적었다. 이 문장은 아직 최종 위반 판정이 아니다. ICO도 문의가 진행 중이라고 notes에 남겼다. ICO · enquiries ongoing

그래도 운영 메시지는 꽤 선명하다. Richard Nevinson은 “AI agents act with autonomy is not an excuse for poor compliance”라고 말했다. ICO · autonomy quote 생활어로 풀면 이렇다. “에이전트가 알아서 한 일이라서 우리도 몰랐다”는 설명만으로는 부족하다. 어떤 데이터에 접근하도록 설계했는지, 어떤 보호장치를 뒀는지, 문제가 생겼을 때 어떻게 멈추고 설명할 수 있는지가 남아야 한다.

실무 체크 1: 목적과 데이터 범위를 먼저 쓴다

AI 에이전트 도입 문서는 모델 이름으로 시작하지 않는 편이 좋다. 첫 줄은 목적이어야 한다. 예를 들어 “고객 문의를 요약한다”, “지원 티켓에서 중복 이슈를 찾는다”, “채용 지원자의 일정을 조율한다”는 서로 다른 일이다. 목적이 달라지면 필요한 개인정보도 달라진다.

ICO의 기존 AI 데이터 보호 가이드는 AI에도 accountability, governance, transparency, lawfulness, fairness 같은 데이터 보호 원칙을 적용해 설명한다. ICO AI data protection guidance 에이전트에 대입하면 질문은 더 구체적이다. 이 에이전트가 이름, 이메일, 위치, 결제 정보, 민감한 메모 중 무엇을 읽는가. 읽은 정보를 어디에 저장하는가. 답변을 만들기 위해 외부 모델이나 도구로 보내는가. 자동으로 제출하거나 수정하는 순간이 있는가.

실무 체크 2: 도구 권한은 한 덩어리로 주지 않는다

에이전트가 “웹을 쓸 수 있다”는 말은 너무 크다. 검색만 하는지, 로그인된 세션을 쓰는지, 폼을 제출하는지, 파일을 내려받는지, 결제를 시작하는지에 따라 위험이 달라진다. 그래서 권한표는 최소한 읽기, 쓰기, 제출, 외부 전송, 자동 결정으로 나누는 편이 안전하다.

가장 위험한 착각은 “사람이 시켰으니 괜찮다”다. 사람은 큰 목표를 줬지만, 에이전트가 중간 경로에서 어떤 페이지를 열고 어떤 API를 호출할지는 계속 달라질 수 있다. 따라서 고위험 행동은 사람 승인, 샘플 검토, 중단 버튼, 로그 보존이 붙어야 한다. 고객 데이터 수정, 외부 메시지 발송, 결제, 계정 권한 변경은 특히 자동 실행보다 승인 대기 기본값이 낫다.

실무 체크 3: 사고가 아니라 ‘설명 실패’를 막는다

에이전트 사고 대응에서 가장 먼저 무너지는 것은 기억이다. 무슨 프롬프트였는지, 어떤 도구가 켜져 있었는지, 어떤 페이지를 읽었는지, 어떤 데이터가 외부로 나갔는지 나중에 모르면 개선도 해명도 어렵다. 그래서 로그는 디버깅용 옵션이 아니라 개인정보 거버넌스의 일부다.

다만 로그를 많이 남기는 것만으로 안전해지는 것도 아니다. 로그 자체가 개인정보 저장소가 될 수 있기 때문이다. 남겨야 할 것은 “모든 원문”이 아니라 설명에 필요한 최소 증거다. 목적, 입력 데이터 범주, 사용 도구, 승인 여부, 외부 전송 여부, 결과 변경 여부, 중단·롤백 경로가 핵심이다. 민감한 원문은 마스킹하거나 보존 기간을 짧게 두는 방식까지 같이 정해야 한다.

팀 회의에서 바로 쓸 5문장 체크리스트

1. 이 에이전트의 목적은 한 문장으로 설명되는가.
2. 목적에 꼭 필요한 개인정보 범주만 열려 있는가.
3. 읽기, 쓰기, 제출, 외부 전송, 자동 결정을 따로 승인하는가.
4. 고위험 행동 전에 사람 승인과 중단 경로가 있는가.
5. 나중에 설명할 수 있는 최소 로그와 보존 기간이 정해져 있는가.

이 다섯 문장을 통과하지 못하면, 모델을 더 좋은 것으로 바꿔도 위험은 크게 줄지 않는다. 좋은 모델은 실수를 줄일 수 있지만, 권한이 너무 넓고 증거가 없으면 작은 실수도 큰 개인정보 사고로 커진다.

어디까지가 한계인가

오늘 글은 영국 ICO 발표를 기준으로 한 운영 체크리스트다. 한국 서비스에 곧바로 같은 의무가 생겼다고 단정하는 글은 아니다. 또 ICO가 언급한 문의는 진행 중이며, 개별 기업의 위반 여부를 확정한 문장도 아니다. 다만 실무 신호는 충분하다. 규제기관은 에이전트를 “챗봇의 다음 버전”이 아니라 개인정보를 실제로 움직일 수 있는 실행 시스템으로 보기 시작했다.

따라서 지금 할 일은 겁먹고 에이전트를 모두 막는 것이 아니다. 작은 범위에서 목적을 정하고, 데이터 접근을 줄이고, 도구 권한을 나누고, 승인·로그·롤백을 붙여야 한다. 에이전트가 유용해질수록 이 표는 더 귀찮아지지만, 바로 그 귀찮음이 나중의 설명 비용을 줄인다.

자주 묻는 질문

우리 회사가 영국 기업이 아니어도 봐야 하나요?

네, 규제 신호로는 볼 만하다. ICO 발표 자체가 모든 국가의 즉시 의무는 아니지만, 에이전트가 개인정보와 외부 도구를 함께 다룰 때 어떤 질문이 나오는지 잘 보여준다. 특히 글로벌 고객, 해외 서비스, 다국적 SaaS를 쓰는 팀이라면 미리 권한표와 로그 기준을 갖추는 편이 안전하다.

에이전트가 개인정보를 전혀 안 읽으면 괜찮나요?

위험은 줄어든다. 하지만 “전혀 안 읽는다”는 말도 검증이 필요하다. 로그인 세션, 브라우저 쿠키, 파일 첨부, CRM 화면, 고객 문의 본문처럼 의도치 않게 개인정보가 들어오는 경로가 있는지 봐야 한다. 읽지 않는 설계라면 차단 설정과 테스트 증거를 남기는 것이 좋다.

로그를 많이 남기면 규정 준수가 쉬워지나요?

무조건 그렇지는 않다. 로그는 설명에 필요하지만, 원문 개인정보를 오래 많이 저장하면 또 다른 위험이 된다. 필요한 범주, 마스킹, 접근 권한, 보존 기간을 같이 정해야 한다.

지금 당장 무엇부터 하면 되나요?

에이전트별로 목적, 접근 데이터, 사용 도구, 자동 실행 범위, 사람 승인 지점을 한 장 표로 적어 보자. 표를 만들 수 없으면 아직 운영 준비가 덜 된 것이다. 표가 만들어지면 다음 단계는 실제 로그와 중단 경로가 표대로 작동하는지 작은 테스트로 확인하는 일이다.