ai-governance

5 개의 포스트

cloudflare

신원 인식형 분석으로 통제 불능 AI 행동 포착하기 (새 탭에서 열림)

AI 사용량의 이상 징후를 파악하려면 요청마다 검증된 사용자·에이전트 신원과 각 계정의 정상적인 사용 기준선이 필요하다. Cloudflare는 AI Gateway와 Cloudflare Access를 결합해 요청별 신원을 확인하고, User Insights로 계정별 사용 패턴에서 벗어난 행동을 탐지한다고 밝혔다. 이를 통해 비용 관리뿐 아니라 과도한 사용이나 악성·오작동 에이전트 탐지까지 가능하게 한다. ## AI Gateway를 통한 중앙 관리 - AI Gateway는 OpenAI, Anthropic, Google, Workers AI 등 여러 모델로 향하는 요청을 하나의 제어 지점으로 통합한다. - 애플리케이션뿐 아니라 Claude Code, Codex, GitHub Copilot 같은 개발자용 에이전트도 동일한 관찰·보안·거버넌스 정책을 적용할 수 있다. - 모든 AI 트래픽을 한곳에서 분석하므로 비용, 모델 사용량, 접근 제어를 통합 관리할 수 있다. ## Cloudflare Access 기반의 신원 확인 - AI Gateway 앞에 사용자 정의 도메인을 두고 Cloudflare Access로 보호할 수 있다. - Okta, Entra 등 SAML을 지원하는 ID 공급자를 이용해 인증하며, 별도의 Cloudflare API 키를 배포할 필요가 없다. - 인증된 요청에는 사용자의 Access ID가 `cf.user_id` 메타데이터로 포함된다. - 관리자는 실제 요청자를 기준으로 로그, 분석 데이터, 비용을 필터링할 수 있다. - 공유 API 키 때문에 누가 얼마나 사용했는지 알기 어려웠던 문제를 해결한다. ## 사용자별 비용 한도와 정책 - `cf.user_id`를 기반으로 사용자마다 독립적인 예산 한도를 설정할 수 있다. - 한도에 도달하면 요청을 차단하거나 더 저렴한 모델로 자동 전환할 수 있다. - 향후 ID 공급자의 그룹 정보와 연동해 팀별로 모델 접근 권한과 지출 한도를 설정할 예정이다. - 머신러닝 팀에는 최고급 모델 허용 - 지원팀에는 지출 상한 적용 - 특정 프로젝트 구성원에게 공동 예산 할당 ## User Insights의 역할 - User Insights는 AI Gateway를 통과하는 기존 트래픽을 별도 설정 없이 분석한다. - 사람과 에이전트 각각의 평소 행동 패턴을 학습하고, 그 패턴에서 벗어난 계정을 보여준다. - 비용뿐 아니라 캐시 적중률이 낮거나 컨텍스트 윈도우가 과도하게 큰 등 비용 낭비 요인도 추적한다. - 단순히 “많이 사용했는가”가 아니라 “그 계정의 평소 사용 방식과 다른가”를 판단하는 데 초점을 둔다. ## 사람과 에이전트별 행동 기준선 - 계정은 사용자든 에이전트든 시간에 따라 고유한 행동 패턴을 만든다. - 일정한 간격으로 티켓을 요약하는 에이전트와, 프롬프트·세션 길이가 불규칙한 사람은 정상 패턴이 다르다. - 따라서 모든 계정에 동일한 절대 비용 기준을 적용하면 오탐이 많아진다. - 평소 비용이 큰 사용자의 500달러 지출은 정상일 수 있다. - 평소 5달러를 쓰는 에이전트의 50달러 세션은 10배 증가한 이상 징후일 수 있다. ## 세션 비용 기반 이상 탐지 - User Insights는 개별 요청이 아니라 세션 단위로 비용을 평가한다. - 최근 30일 동안 해당 계정의 세션 비용 p95를 개인 기준선으로 사용한다. - 세션 비용이 개인 p95의 2배를 초과하면 이상 행동 후보로 분류한다. - 단, 상대적 급증만으로는 부족하므로 조직 전체 세션 비용의 p99도 함께 사용한다. - 최종적으로 다음 조건을 모두 만족하는 세션만 경고 대상이 된다. - 해당 계정의 최근 기준선보다 2배 이상 비쌈 - 조직 전체 세션 중 가장 비싼 1% 수준에 해당함 - 절대 비용 하한선도 적용해, 소액 사용자의 몇 센트짜리 급증이 불필요한 경고를 발생시키지 않도록 한다. ## 동적으로 갱신되는 기준선 - 기준선은 고정값이 아니라 계정의 최근 사용 습관에 따라 계속 변한다. - 계정의 rolling p95와 2배 임계값이 이동하므로 현재 행동에 맞는 경고가 가능하다. - 정상적인 고사용자 활동은 제외하고, 평소 패턴을 깨면서도 실제 조사 가치가 있는 고비용 세션만 추린다. - 결과적으로 관리자는 정상 트래픽을 모두 살펴보는 대신, 의심스러운 계정 중심의 “rogue behavior feed”를 확인할 수 있다. ## 보안과 비용 관리의 결합 - 이상 사용은 새로운 도구나 명백히 차단된 행동으로 나타나지 않을 수 있다. - 이미 권한을 가진 계정이나 서비스 계정이 허용된 작업을 평소보다 훨씬 많이 수행하는 방식으로 나타날 수 있다. - 따라서 사용자 신원 확인과 행동 기준선 분석을 함께 적용해야 비용 폭증과 보안 위험을 동시에 발견할 수 있다. 실무적으로는 모든 AI 요청을 AI Gateway로 통합하고, Cloudflare Access로 개인·에이전트 신원을 연결한 뒤, 사용자별 예산과 User Insights의 상대적 기준선을 함께 활용하는 방식이 권장된다.

figma

검증할 수 있는 신뢰: Figma, 이제 ISO 42001 인증 획득 | Figma 블로그 (새 탭에서 열림)

Figma는 AI 거버넌스 관리 체계(AIMS)에 대해 국제 표준 ISO/IEC 42001:2023 인증을 획득했다고 발표했습니다. 이번 인증은 자체 설명이 아니라 ANAB 공인 인증기관인 Schellman의 독립적인 심사를 통해 정책, 위험 관리, 데이터 관행, 기술적 보호조치가 실제로 운영되고 있음을 검증받았다는 의미입니다. Figma는 이를 통해 규제 산업 고객이 AI 관련 공급업체 위험 평가와 규제 보고에 활용할 수 있는 객관적 근거를 제공한다고 강조합니다. ## ISO/IEC 42001과 AI 관리 시스템 - ISO/IEC 42001은 2023년 12월 제정된 AI 관리 시스템 국제 표준입니다. - 정보보호 관리체계 표준인 ISO 27001과 유사하게, 조직이 AI를 책임 있게 개발·배포·운영하기 위해 필요한 정책과 절차, 통제 항목을 정의합니다. - AI 관리 시스템(AIMS)은 다음 활동을 관리하는 운영 기반입니다. - AI 기능의 설계와 개발 - 제품 내 AI 배포 - 데이터 및 위험 관리 - 성능과 영향 모니터링 - 인간의 감독과 책임 체계 유지 ## 자체 문서보다 독립적 검증이 중요한 이유 - AI 공급업체는 백서, 보안 설문, 정책 문서 등을 통해 거버넌스 수준을 설명할 수 있지만, 문서만으로는 실제 통제가 작동하는지 판단하기 어렵습니다. - ISO 42001 인증은 공인된 제3자가 국제 표준에 따라 관리 체계를 직접 심사했다는 점에서 자체 평가와 구별됩니다. - Figma는 Schellman이 다음 항목을 검토했다고 설명합니다. - AI 거버넌스 정책 - 데이터 처리 관행 - AI 위험 관리 절차 - 기술적 보호조치 - 실제 운영 효과 - 따라서 고객은 Figma의 설문 답변만 검토하는 대신, 벤더 위험 평가·이사회 보고·규제 제출에 활용할 수 있는 외부 검증 결과를 참고할 수 있습니다. ## 인증 적용 범위 - 인증 대상은 Figma 플랫폼 전반의 AI 기능을 관리하는 AIMS입니다. - 적용 제품은 다음과 같습니다. - Figma Design - Figma Make - FigJam - Dev Mode - Figma Sites - Figma Slides - Figma Draw - Figma Buzz - Figma Weave ## 실제 심사 방식과 9개 통제 목표 - 심사는 두 단계로 진행되었습니다. - **1단계:** AIMS의 설계, 문서, 정책, 위험 평가 방법론 검토 - **2단계:** 직원 인터뷰, 업무 프로세스 관찰, 실제 운영 효과 평가 - 총 38개 통제를 다음 9개 Annex A 통제 목표에 따라 평가했습니다. - AI 영향 평가 - 거버넌스와 책임 - AI 특화 위험 관리 - AI 시스템 생명주기 관리 - 데이터 거버넌스 - 제3자 AI 위험 관리 - 모니터링과 성능 평가 - 인간의 감독 - AI 시스템의 책임 있는 사용 - Figma는 이번 인증이 관련 개념을 문서화했다는 사실보다, 실제 프로세스에 적용하고 운영하고 있음을 검증한 데 의미가 있다고 설명합니다. - 인증기관 자체도 ANAB의 공인을 받았기 때문에, 비공인 기관의 인증보다 신뢰성과 객관성이 높다고 강조합니다. ## 규제 산업 고객에게 의미하는 점 - Figma의 AI 기능은 금융, 의료, 보험, 공공 부문 등 보안·개인정보·규제 요구가 높은 환경에서 사용될 수 있습니다. - 이런 조직은 AI 공급업체를 평가할 때 다음을 입증해야 할 수 있습니다. - AI 위험을 식별하고 관리하는지 - 데이터가 적절히 통제되는지 - AI 시스템에 인간의 감독이 존재하는지 - 공급업체의 통제가 실제로 운영되는지 - EU AI 법(EU AI Act)과 새로운 AI 조달 기준은 단순한 선언보다 증빙을 요구하는 방향으로 발전하고 있습니다. - ISO 42001 인증은 기업의 벤더 위험 관리, 감사 대응, 이사회 보고, 규제 제출에 활용 가능한 공식 근거가 될 수 있습니다. ## 향후 지속적인 검증 - Figma는 AI 기능이 확대될수록 거버넌스 체계도 계속 제3자 검증에 맡기겠다고 밝혔습니다. - ISO 42001 인증서는 기존 ISO 27001 및 SOC 2 Type II 인증과 함께 제공됩니다. - 인증서와 보안·컴플라이언스 문서는 `compliance.figma.com`에서 확인할 수 있으며, Schellman 인증서 디렉터리를 통해 인증을 검증할 수 있습니다. - Figma는 AI 거버넌스가 변경되어 고객의 위험 평가에 영향을 줄 경우 이를 투명하게 알리고, 관련 정보를 지속적으로 최신 상태로 유지하겠다고 약속합니다. 실무적으로는 AI 서비스를 도입하거나 갱신할 때 공급업체의 자체 설명만 확인하기보다, ISO 42001처럼 공인기관이 검증한 인증 범위·유효기간·적용 제품을 함께 확인하는 것이 바람직합니다.

gitlab

취약점 통합 관점: 스캐너 커버리지에서 AI 거버넌스까지 (새 탭에서 열림)

GitLab 19.1은 여러 보안 스캐너의 결과와 적용 범위를 하나의 취약점 화면에서 관리하고, 프로젝트 전체에 스캐너 정책을 강제할 수 있도록 한다. 또한 시크릿 탐지 정확도를 높이고, AI 에이전트의 도구 사용을 승인 절차와 감사 로그로 통제해 자동화와 보안을 함께 확보하는 것이 글의 핵심이다. 궁극적으로 목표는 검증 가능한 스캐너 적용 범위와 통제된 AI 에이전트 자율성이다. ## 서드파티 스캐너 적용 범위의 중앙 관리 - 기업에서는 프로젝트마다 서로 다른 보안 스캐너를 설정하는 경우가 많아, 어떤 프로젝트가 실제로 검사되고 있는지 파악하기 어렵다. - 신규 프로젝트가 스캐너 설정에서 빠지면 몇 주 동안 검사되지 않은 코드가 배포될 수 있다. - GitLab 19.1에서는 **SARIF 형식으로 결과를 출력하는 서드파티 스캐너**를 GitLab 정책에 따라 모든 프로젝트에 적용할 수 있다. - 각 스캐너의 결과는 GitLab의 단일 취약점 화면으로 통합되며, 동일한 정책과 규칙으로 관리된다. - 이를 통해 스캐너 적용 범위를 추정하는 대신 감사나 보고에서 입증할 수 있다. ## 서드파티 취약점의 자동 remediation - 서드파티 스캐너에서 발견한 취약점도 GitLab 네이티브 스캐너 결과와 동일한 자동화 흐름에 포함된다. - **SAST False Positive Detection**이 오탐 가능성을 분류해 실제 위험이 높은 이슈를 우선 처리한다. - **Agentic SAST Vulnerability Resolution**은 수정안을 생성하고 바로 병합할 수 있는 머지 리퀘스트를 자동으로 연다. - 결과적으로 취약점이 프로덕션에 도달하기 전에 자동 수정할 가능성이 높아진다. ## 시크릿 탐지 범위 확대와 오탐 감소 - 기존에는 새 브랜치에서 최신 커밋만 검사했기 때문에, 이전 커밋에 포함된 비밀 정보가 탐지되지 않을 수 있었다. - 이제 새 브랜치의 **모든 커밋을 검사**해 시크릿이 처음 도입된 지점을 놓칠 가능성을 줄인다. - 정식 출시된 **Secret False Positive Detection**은 각 탐지 결과에 신뢰도 점수와 설명을 제공한다. - 테스트용 자격 증명, 예시 토큰, 플레이스홀더 값과 실제 유출된 비밀 정보를 구분하는 데 도움을 준다. - 개발자는 오탐을 정리하는 데 쓰는 시간을 줄이고 실제 자격 증명 노출에 집중할 수 있다. ## AI 에이전트의 도구 사용 통제 - 코딩 에이전트는 머지 리퀘스트 생성, 도구 호출, 코드 커밋 등을 수행할 수 있지만, 승인 후에는 파일 작성·삭제·푸시까지 자동으로 실행할 위험이 있다. - 조직은 에이전트가 행동하기 전에 허용 범위를 정하고, 행동 이후에는 무엇을 했는지 증명할 수 있어야 한다. - 베타 기능인 **Agent tool approval guardrails**를 사용하면 관리자마다 에이전트 도구를 다음처럼 설정할 수 있다. - 자동 실행 - 사람의 승인 후 실행 - 실행 차단 - 파일 작성이나 리소스 삭제처럼 민감한 작업은 담당자의 승인 전까지 보류할 수 있다. ## AI 감사 이벤트와 책임 추적 - 베타 기능인 **AI audit event streaming**은 에이전트의 모든 활동을 감사 이벤트로 기록하고 기존 감사 로그 저장소로 스트리밍한다. - 사람이 승인하거나 거부한 결정도 감사 이벤트로 남는다. - 사고 대응이나 감사 시 에이전트가 언제 어떤 도구를 사용했고, 어떤 변경을 수행했는지 확인할 수 있다. - 이를 통해 에이전트가 완전히 제한되는 것이 아니라, 사전에 정한 경계 안에서 자율적으로 작업하는 **통제된 자율성(governed autonomy)**을 구현한다. ## 실용적인 적용 방향 조직은 먼저 모든 프로젝트에 SARIF 기반 스캐너 정책을 강제해 보안 검사 공백을 제거하고, 통합 취약점 화면에서 결과를 관리하는 것이 좋다. 이후 시크릿 탐지와 오탐 분류를 활성화하고, AI 에이전트에는 파일 삭제·코드 푸시 등 고위험 작업에 사람 승인과 감사 로그를 적용하는 방식이 적절하다.

gitlab

GitHub Copilot의 AI 학습 정책: 거버넌스를 향한 경종 (새 탭에서 열림)

GitHub Copilot이 2026년 4월부터 사용자 데이터를 모델 학습에 기본적으로 활용하겠다고 발표함에 따라, 기업 데이터 거버넌스에 대한 경각심이 높아지고 있습니다. 이러한 정책 변화는 특히 금융, 의료, 국방 등 규제가 엄격한 산업군에서 지적 재산권 유출과 규제 준수 리스크를 초래할 수 있습니다. 이에 대응하여 GitLab은 모든 요금제에서 고객 데이터를 학습에 사용하지 않는다는 원칙을 고수하며, 투명하고 감사 가능한 AI 거버넌스의 필요성을 강조하고 있습니다. ## GitHub 정책 변경의 주요 내용과 영향 * 2026년 4월 24일부터 Copilot Free, Pro, Pro+ 사용자의 입력값(Inputs), 출력값(Outputs), 코드 스니펫 및 관련 컨텍스트가 기본적으로 AI 모델 학습에 사용됩니다. * 학습에 활용되는 데이터는 마이크로소프트(Microsoft)를 포함한 GitHub 계열사와 공유될 수 있으며, 사용자가 이를 원치 않을 경우 직접 '옵트아웃(Opt-out)' 설정을 해야 합니다. * 이러한 변화는 기업들이 현재 사용 중인 AI 도구의 라이선스 등급을 재검토하고, 내부 보안 컨트롤이 적절히 구성되어 있는지 다시 확인해야 하는 계기가 되고 있습니다. ## 규제 산업에서 AI 거버넌스가 필수적인 이유 * **지적 재산(IP) 보호**: 소스 코드는 독점 알고리즘, 사기 탐지 로직, 거래 전략 등 기업의 핵심 자산을 포함하고 있으며, AI 모델 학습에 사용될 경우 경쟁사에게 해당 로직이 노출될 위험이 있습니다. * **규제 준수 요구사항**: 금융권의 모델 리스크 관리 지침(SR 11-7)이나 유럽의 디지털 운영 탄력성법(DORA) 등은 제3자 기술 제공자가 데이터를 처리하는 방식에 대해 문서화되고 감사 가능한 감독을 요구합니다. * **공공 및 의료 보안**: 미국 국립표준기술연구소(NIST 800-53)나 의료정보보호법(HIPAA) 등의 기준을 따르는 조직에서는 데이터가 통제된 경계를 벗어나는 것 자체가 운영상의 큰 리스크가 됩니다. ## GitLab이 제안하는 AI 데이터 보호 기준 * **학습 배제 원칙**: GitLab은 요금제와 관계없이 고객 코드를 AI 학습에 절대 활용하지 않으며, 협력하는 AI 벤더(Subprocessor) 또한 고객 데이터를 자체적인 목적으로 사용하지 못하도록 계약으로 금지하고 있습니다. * **AI 투명성 센터 운영**: 어떤 모델이 어떤 기능을 구동하는지, 데이터 보유 기간은 얼마인지, 하위 프로세서와의 관계는 어떠한지 등을 한곳에서 문서화하여 제공함으로써 기업의 감사 업무를 지원합니다. * **독립성 및 중립성 확보**: 특정 클라우드 제공자나 대규모 언어 모델(LLM)에 종속되지 않는 구조를 유지하며, 벤더의 데이터 처리 방식에 중대한 변경이 생길 경우에 대비한 'AI 연속성 계획'을 수립하고 있습니다. ## 실용적인 결론 및 제안 기업의 AI 도입은 이제 선택이 아닌 필수가 되었지만, 도입 과정에서 벤더에게 다음과 같은 구체적인 질문을 던져야 합니다. "우리 데이터가 모델 학습에 사용되는가?", "데이터 정책이 변경될 경우 어떤 보장을 받을 수 있는가?", "모든 AI 처리를 자체 인프라 내에서 수행할 수 있는가?". 단 30일 전의 고지만으로 데이터 활용 정책을 바꿀 수 있는 서비스는 규제 산업군에서 파트너가 아닌 잠재적 부채가 될 수 있습니다. 따라서 계약적 확실성과 감사 가능성을 제공하는 벤더를 선택하여 컴플라이언스 리스크를 선제적으로 관리할 것을 권장합니다.

grammarly

신뢰 연습: 신뢰를 구축하기 위해 필요한 것 (새 탭에서 열림)

교육 현장에서 AI 도입의 핵심은 단순한 기술적 성능이 아닌 '신뢰'의 문제이며, 이 신뢰는 각 교육 단계의 책임 구조에 따라 다르게 정의됩니다. K-12와 고등교육 기관은 AI에 대해 서로 다른 위험 요소를 우선시하므로, 신뢰 형성을 위해서는 각기 다른 책임 모델에 맞춘 맥락 중심적인 접근이 필수적입니다. 단순히 보편적인 투명성을 제공하는 것을 넘어, 실질적인 책임 소재를 명확히 하고 각 교육자의 전문성을 존중하는 파트너십이 AI 거버넌스의 성패를 결정합니다. ## K-12 환경에서의 신뢰: 관리와 보호 (Stewardship) * K-12 단계에서 신뢰는 학생의 안전, 학부모의 기대, 그리고 학교의 '보호자적 의무'와 밀접하게 연결되어 있습니다. * 관리자와 교육자들은 AI 시스템이 학생을 안전하게 보호할 수 있는지, 그리고 예기치 못한 문제가 발생했을 때 기관을 방어할 수 있는지를 가장 중요하게 평가합니다. * 이 맥락에서 신뢰는 집단적이고 제도적인 성격을 띠며, 명확한 가이드라인과 책임 공유 모델이 제시될 때 강화됩니다. 반대로 데이터나 책임 소재가 모호할 경우 기술적 완성도와 상관없이 신뢰는 즉각적으로 무너집니다. ## 고등교육에서의 신뢰: 자율성과 전문성 (Autonomy & Credibility) * 대학 등 고등교육 기관에서 신뢰는 학문적 정직성, 저술 권한, 지적 소유권과 같은 개인적이고 전문적인 영역에 집중됩니다. * 교수진은 AI 도구가 학자이자 교육자로서의 자신의 역할을 지원하는지, 아니면 자신의 전문적 판단과 권위를 훼손하는지를 핵심 척도로 삼습니다. * K-12에서 안도감을 주던 강력한 통제나 보호 장치가 고등교육 환경에서는 오히려 자율성을 침해하는 위협으로 인식될 수 있다는 점에서 교육 단계별로 다른 접근이 필요합니다. ## 교육자들이 요구하는 실질적인 명확성 * 모든 교육 단계에서 공통적으로 요구하는 것은 단순한 위로나 안심이 아니라, 시스템 작동 방식에 대한 구체적인 '명확성'입니다. * 교육자들은 AI가 실제로 무엇을 수행하는지, 오류 발생 시 누가 책임을 지는지, 그리고 자신의 전문적 판단과 학생들의 학습 결과물에 어떤 영향을 미치는지를 알고자 합니다. * 투명성이나 설명 가능성 같은 추상적인 원칙보다, 교육자가 현장에서 마주하는 실제적인 책임과 시스템의 기능을 일치시키는 것이 신뢰 구축의 핵심입니다. ## 맥락 인식을 통한 AI 거버넌스 구축 * 신뢰는 한 번 설계하여 일괄적으로 배포할 수 있는 기능이 아니며, 각 교육 단계의 역할과 위험 요소에 민감하게 반응하는 '맥락 인식형(Context-aware)' 설계가 필요합니다. * 성공적인 AI 거버넌스를 구축하는 기관들은 기술적 결정을 내릴 때 그것이 기관의 가치를 어떻게 반영하는지, 그리고 누구를 신뢰하고 있는지를 대외적으로 명확히 전달합니다. * 결론적으로 AI 플랫폼과 파트너들은 교육 현장의 복잡성을 단순화하기보다 이를 존중하고, 사용자가 자신의 역할에 대해 느끼는 책임감을 기술 디자인에 반영해야 합니다.