WEBVTT

00:00:00.000 --> 00:00:02.700
귀사의 경영진은 이것을 단순한 배포 문제라고 생각합니다.

00:00:02.900 --> 00:00:03.660
그렇지 않습니다.

00:00:03.920 --> 00:00:06.200
이는 매우 촉박한 시간 내에 내려야 할 거버넌스 결정이며

00:00:06.200 --> 00:00:09.020
코파일럿은 귀사의 정책 정비나 내부 조정이 완료될 때까지

00:00:09.020 --> 00:00:10.740
기다려주지 않기 때문에 압박감이 큽니다.

00:00:10.880 --> 00:00:12.900
코파일럿 이 환경 전반에서 작동하기 시작하면

00:00:12.900 --> 00:00:14.780
현재 시스템 상태를 그대로 사용하며

00:00:14.780 --> 00:00:16.360
바로 그 지점에서 문제가 발생합니다.

00:00:16.540 --> 00:00:19.480
마이크로소프트 365 테넌트를 여러 개 사용하는 대부분의 조직은

00:00:19.480 --> 00:00:20.860
단일 공급업체로부터 구매하고

00:00:20.860 --> 00:00:22.520
하나의 아이디 체계를 관리한다는 이유로

00:00:22.520 --> 00:00:24.900
AI 제어 방식 또한 하나일 것이라고 가정합니다.

00:00:24.900 --> 00:00:27.340
이들은 마이크로소프트 위 단일 전략적 서사를 듣고

00:00:27.340 --> 00:00:29.280
현실도 그 설명과 같을 것이라 생각합니다.

00:00:29.440 --> 00:00:31.280
하지만 실제 운영 환경은 매우 다릅니다.

00:00:31.500 --> 00:00:32.900
AI는 테넌트 경계에서 작동하지만

00:00:32.900 --> 00:00:34.460
위험은 그 경계를 넘어 바로 이동합니다.

00:00:34.620 --> 00:00:37.640
따라서 문제는 코파일럿을 어디든 활성화할 수 있는가가 아닙니다.

00:00:37.840 --> 00:00:40.100
진정한 질문은 독립적으로 작동하는 테넌트 전반에서

00:00:40.100 --> 00:00:42.580
안전하게 확장할 수 있는 거버넌스 모델은 무엇인가입니다.

00:00:42.820 --> 00:00:45.740
그 모델을 살펴보기 전에 우리는 함정을 정의해야 합니다.

00:00:45.920 --> 00:00:49.180
함정, 하나의 기업 내에 존재하는 독립적인 AI 섬들

00:00:49.180 --> 00:00:52.160
대부분의 조직에서의 착각은 친숙함에서 시작됩니다.

00:00:52.160 --> 00:00:56.500
마이크로소프트 365, 퍼뷰, 엔트라, 파워 플랫폼을 열어봅니다.

00:00:56.660 --> 00:00:58.000
브랜딩은 모두 동일합니다.

00:00:58.220 --> 00:01:00.280
관리 용어도 서로 연결된 것처럼 느껴집니다.

00:01:00.460 --> 00:01:02.880
그리고 상업적 제안은 매우 깔끔한 이야기를 전달합니다.

00:01:03.080 --> 00:01:05.660
하나의 생태계, 하나의 전략, 하나의 방향

00:01:05.660 --> 00:01:07.600
하지만 그 이면의 제어 모델은 하나가 아니면

00:01:07.600 --> 00:01:09.680
이는 브랜딩보다 훨씬 더 중요합니다.

00:01:09.880 --> 00:01:10.940
여기에 대한 연구에 따르면

00:01:10.940 --> 00:01:13.980
모든 테넌트에서 코파일럿을 깔끔하게 거버넌스할 수 있는

00:01:13.980 --> 00:01:17.260
완전한 기능의 단일 글로벌 AI 관리센터는 존재하지 않습니다.

00:01:17.460 --> 00:01:20.100
실제로 귀사가 가진 것은 파편화된 제어 스택입니다.

00:01:20.100 --> 00:01:23.180
거버넌스의 일부는 퍼뷰에, 다른 부분은 관리센터에,

00:01:23.460 --> 00:01:25.720
나머지는 엔트라와 파워 플랫폼에 흩어져 있습니다.

00:01:25.940 --> 00:01:28.780
최신 마이크로소프트 제어계층에서 일부 기능이 등장하고 있지만

00:01:28.780 --> 00:01:31.220
아직 모든 테넌트의 경계를 아우르는 완벽하고

00:01:31.220 --> 00:01:33.240
성숙한 글로벌 평면을 형성하지는 못했습니다.

00:01:33.500 --> 00:01:35.600
그 간극이 잘못된 자신감을 만듭니다.

00:01:35.800 --> 00:01:38.280
리더들은 생태계를 보고 중앙 집중화를 가정하고

00:01:38.280 --> 00:01:41.300
팀들은 공유된 아이디를 보고 일관성을 가정합니다.

00:01:41.520 --> 00:01:44.020
구매부서는 단일 계약을 보고 단일 운영 모델을 가정하지만

00:01:44.020 --> 00:01:47.320
각 테넌트는 여전히 자체 정책 경계와 데이터 경계를 가지고 있으며

00:01:47.320 --> 00:01:50.540
이는 실제로 각 테넌트가 저마다의 진실을 가지고 있음을 의미합니다.

00:01:50.700 --> 00:01:52.660
그러니 실제로 벌어지고 있는 일은 간단합니다.

00:01:52.860 --> 00:01:55.140
귀사는 하나의 엔터프라이즈 AI 환경을 가지고 있지 않습니다.

00:01:55.300 --> 00:01:58.180
귀사는 같은 기업에 속해 있을 뿐인 여러 개의 AI 환경을 가지고 있는 것입니다.

00:01:58.380 --> 00:01:59.880
그것은 매우 다른 위험 상황입니다.

00:02:00.120 --> 00:02:02.180
어떤 테넌트는 퍼뷰 적용 범위가 더 강력할 수 있고

00:02:02.180 --> 00:02:04.160
다른 테넌트는 네이블 재택이 약하거나

00:02:04.160 --> 00:02:05.800
감사 데이터 수집이 불안전할 수 있습니다.

00:02:06.020 --> 00:02:08.400
이사회 차원에서는 이것이 하나의 프로그램처럼 보일 수 있지만

00:02:08.400 --> 00:02:11.440
감사나 사고 대응 관점에서는 결코 하나의 프로그램이 아닙니다.

00:02:11.580 --> 00:02:13.860
이는 별개의 운영 조건들이 모인 집합체일 뿐입니다.

00:02:14.060 --> 00:02:16.740
일단 그런 조건들이 어긋나기 시작하면 보고는 거짓을 말하게 됩니다.

00:02:16.940 --> 00:02:18.800
위도적인 것이 아니라 구조적으로 그렇습니다.

00:02:18.980 --> 00:02:19.860
핵심팀이 묻습니다.

00:02:20.140 --> 00:02:21.780
우리에겐 거버넌스가 갖춰져 있나요?

00:02:21.920 --> 00:02:23.760
어떤 테넌트는 감사 기능이 켜져 있으니 그렇다고 하고

00:02:23.760 --> 00:02:26.460
다른 곳은 적용 범위가 취약해도 라벨이 존재하니 그렇다고 합니다.

00:02:26.460 --> 00:02:28.880
또 다른 곳은 아이디가 연결되어 있으니 그렇다고 합니다.

00:02:29.060 --> 00:02:32.100
네 번째 테넌트는 코파일럿 이 기술적으로 배포되었으니 그렇다고 답합니다.

00:02:32.320 --> 00:02:34.200
각각의 답변은 그 자체로는 합리적으로 들리지만

00:02:34.200 --> 00:02:35.500
그 의미는 모두 다릅니다.

00:02:35.720 --> 00:02:36.780
그것이 바로 함정입니다.

00:02:37.060 --> 00:02:39.120
여러분은 글로벌 제어 평면을 보고 있다고 생각하지만

00:02:39.120 --> 00:02:42.760
실제로는 한 회사 내에 존재하는 독립적인 AI 섬들을 보고 있는 것입니다.

00:02:42.960 --> 00:02:45.420
브랜드나 때로는 아이디로 연결되어 있을 뿐

00:02:45.420 --> 00:02:47.200
하나의 시스템으로 통제되지 않습니다.

00:02:47.440 --> 00:02:50.740
이 섹션에서 다른 것은 다 있더라도 이 한 문장만은 기억하십시오.

00:02:50.740 --> 00:02:52.560
전체적인 AI 관리센터는 없으며

00:02:52.560 --> 00:02:54.700
단지 존재한다는 환상만이 있을 뿐입니다.

00:02:54.860 --> 00:02:58.000
그 환상이 깨지는 순간 다음 문제는 빠르게 드러납니다.

00:02:58.000 --> 00:03:02.520
대부분의 조직은 테넌트별로 수동 거버넌스를 수행하며 이를 통제라고 부릅니다.

00:03:02.740 --> 00:03:05.880
왜 테넌트별 수동 거버넌스가 규모가 커지면 무너지는지 알아봅시다.

00:03:06.060 --> 00:03:09.120
리더들이 경계 문제를 인식하고 나면 보통은 합리적인 대응책을 내놓습니다.

00:03:09.380 --> 00:03:11.580
그들은 각 테넌트를 제대로 거버넌스 하겠다고 말합니다.

00:03:11.800 --> 00:03:14.840
한 관리팀이 설정을 확인하면 다른 팀이 또 거기서 똑같은 설정을 반복합니다.

00:03:15.060 --> 00:03:16.320
누군가는 스프레드 시트를 유지하고

00:03:16.320 --> 00:03:18.080
또 다른 누군가는 체크리스트를 만듭니다.

00:03:18.240 --> 00:03:21.480
운영위원회가 매달 모여 배포가 계획대로 진행되고 있는지 묻습니다.

00:03:21.760 --> 00:03:23.400
서류상으로는 체계적으로 보입니다.

00:03:23.400 --> 00:03:26.880
하지만 실제로는 거버넌스로 포장된 수동 작업의 반복일 뿐입니다.

00:03:27.020 --> 00:03:28.840
그것이 실패하는 이유는 간단합니다.

00:03:29.040 --> 00:03:32.880
반복은 통제를 낳지 않으며 시간이 지남에 따라 편차만 발생시킵니다.

00:03:33.080 --> 00:03:35.040
각 테넌트는 서로 다른 속도로 움직이고

00:03:35.040 --> 00:03:37.820
각 관리자는 표준을 조금씩 다르게 해석하며

00:03:37.820 --> 00:03:40.500
비즈니스는 중앙 검토를 기다릴 여유가 없기에

00:03:40.500 --> 00:03:42.960
로컬 예외를 정당화하기 시작하기 때문입니다.

00:03:43.160 --> 00:03:45.820
이 낡은 모델이 유지되는 이유는 눈에 보이기 때문입니다.

00:03:46.060 --> 00:03:49.700
사람들은 처리된 티켓, 생성된 정책, 변경된 설정들을 지적할 수 있습니다.

00:03:49.700 --> 00:03:54.000
그들은 활동을 보여줄 수는 있지만 눈에 보이는 노력이 안정적인 운영 모델과 같은 것은 아닙니다.

00:03:54.140 --> 00:03:57.560
그리고 코파일럿이 도입되면 그 격차는 매우 빠르게 비용 부담으로 이어집니다.

00:03:57.760 --> 00:04:01.500
시스템은 사용자가 프롬프트를 입력하는 즉시 기존의 권한, 콘텐츠 노출 상태,

00:04:01.840 --> 00:04:03.180
라벨링 공백을 그대로 활용합니다.

00:04:03.360 --> 00:04:05.380
그것이 바로 사람들이 가장 많이 놓치는 부분입니다.

00:04:05.540 --> 00:04:08.080
코파일럿은 거버넌스가 성숙해질 때까지 기다려주지 않습니다.

00:04:08.280 --> 00:04:13.700
기존의 권한, 그대로 방치한 콘텐츠 위생, 표준화하지 못한 감사 상태 그대로 작동하기 시작합니다.

00:04:13.700 --> 00:04:23.280
한 테넌트는 접근 권한을 정리하고 다른 곳은 삭제하거나 어떤 테넌트는 유용한 감사 데이터를 전송하는데 다른 곳은 조사에 필요한 최소한의 데이터조차 확보하지 못한다면 코파일럿은 그 차이를 즉시 드러낼 것입니다.

00:04:23.460 --> 00:04:26.320
이것은 이론에서 그치지 않고 사용 과정에서 실제로 일어납니다.

00:04:26.500 --> 00:04:31.680
한 테넌트가 광범위한 시어포인트 액세스 권한을 검토하고 다른 테넌트는 괜찮을 것이라 가정했다면 AI는 그 격차를 찾아낼 것입니다.

00:04:31.840 --> 00:04:35.160
한 단계 더 깊이 들어가보면 새로운 테넌트가 추가될 때마다 문제가 배가 됩니다.

00:04:35.160 --> 00:04:38.840
테넌트 자체가 나빠서가 아니라 관리되지 않은 차이점들이 쌓이기 때문입니다.

00:04:39.000 --> 00:04:45.680
새로운 파일럿팀이 로컬 예외사항을 추가하고 합병으로 서로 다른 네이블을 가진 테넌트가 들어오며 지역관리자가 이전 기준을 복사합니다.

00:04:45.880 --> 00:04:50.500
사업부에서는 더 빠른 액세스를 요구하지만 개별적인 선택만 놓고 보면 그리 심각해 보이지 않습니다.

00:04:50.720 --> 00:04:54.740
이것들이 몇 달간 쌓이면 정책 편차, 액세스 편차, 배포 편차가 발생하게 됩니다.

00:04:54.940 --> 00:04:58.880
그 결과 거버넌스팀은 리스크 예방보다 차이점을 조정하는데 더 많은 시간을 보내게 됩니다.

00:04:59.120 --> 00:05:01.100
바로 여기서 수동 제어가 한계를 드러냅니다.

00:05:01.100 --> 00:05:07.520
사람이 직접 설정을 다루니 더 안전하게 느껴지지만 실제로는 모든 접점이 테넌트 간의 불일치를 초래함으로 비일관성이 확대됩니다.

00:05:07.660 --> 00:05:13.560
결과적으로 속도가 필요한 곳에서는 배포가 늦어지고 증거가 필요한 곳에서는 감사노력이 늘어나며 표준이 필요한 곳에서는 재작업이 많아집니다.

00:05:13.700 --> 00:05:17.380
무엇보다 최악인 것은 경영진은 확신을 기대하는 상황에서 숨겨진 위험이 발생한다는 점입니다.

00:05:17.540 --> 00:05:20.320
저는 거버넌스를 설정 작업으로 여기는 것을 멈췄을 때의 사실을 깨달았습니다.

00:05:20.580 --> 00:05:21.880
거버넌스는 그런 것이 아닙니다.

00:05:22.060 --> 00:05:23.500
오히려 부패하는 과정과 비슷합니다.

00:05:23.720 --> 00:05:27.700
권한을 한 번 정리하더라도 다시 편차가 발생하는 것을 막을 제어가 없다면 위험은 다시 돌아옵니다.

00:05:27.700 --> 00:05:32.320
레이블 분류 체계를 한 번 정의해도 테넌트별로 다르게 적용한다면 기준은 약화됩니다.

00:05:32.480 --> 00:05:37.640
기본 제어가 여전히 유효한지 확인하지 않고 코파일럿을 순차적으로 승인한다면 그것은 안전한 확장이 아닙니다.

00:05:37.800 --> 00:05:40.840
그저 거버넌스가 따라갈 수 있는 속도보다 더 빠르게 확장하는 것뿐입니다.

00:05:41.020 --> 00:05:43.460
따라서 여기서 중요한 지표는 액세스 편차입니다.

00:05:43.700 --> 00:05:47.920
단순히 문제를 해결했는지가 아니라 해결로 권한이 얼마나 빨리 다시 퍼지는지가 중요합니다.

00:05:48.160 --> 00:05:50.940
그것이 여러분의 모델이 유지되고 있는지 아니면 무너지고 있는지를 알려줍니다.

00:05:51.120 --> 00:05:53.220
거버넌스는 완료할 수 있는 프로젝트가 아니기 때문입니다.

00:05:53.380 --> 00:05:55.660
거버넌스는 지속적으로 관리해야 할 부패의 문제입니다.

00:05:55.660 --> 00:06:00.000
규모가 커져 기존 모델이 무너지면 대부분의 리더는 가장 익숙한 해답인 아이디를 찾습니다.

00:06:00.160 --> 00:06:04.180
사용자가 테넌트 간에 자유롭게 이동할 수 있으면 거버넌스도 따라갈 것이라고 가정합니다.

00:06:04.400 --> 00:06:05.200
그렇지 않습니다.

00:06:05.440 --> 00:06:07.680
왜 아이디만으로는 거버넌스를 해결할 수 없을까요?

00:06:07.880 --> 00:06:10.120
많은 프로그램이 잘못된 길로 들어서는 지점입니다.

00:06:10.340 --> 00:06:12.620
아이디가 명확한 해답처럼 느껴지기 때문입니다.

00:06:12.820 --> 00:06:19.780
사용자가 테넌트 간에 인증할 수 있고 엔트라가 연결되어 있으며 테넌트 간 설정이 완료되면 리더들은 어려운 부분이 해결되었다고 가정합니다.

00:06:19.780 --> 00:06:28.300
액세스와 로그인은 통합되어 보이고 아키텍처 다이어그램은 깔끔해 보이지만 아이디가 이동할 수 있다고 해서 코파일럿 거버넌스가 통합되는 것은 아닙니다.

00:06:28.460 --> 00:06:31.420
그 가정은 AI가 실제로 작동하는 지점에서 무너집니다.

00:06:31.580 --> 00:06:37.240
코파일럿은 요청이 실행되는 테넌트 컨텍스트 내에서 응답의 근거를 찾으며 마이크로소프트 위 가이드라인도의 점을 명확히 하고 있습니다.

00:06:37.520 --> 00:06:44.680
마이크로소프트 365 코파일럿은 테넌트의 보안 및 규정 준수 경계 내에서 작동하며 해당 테넌트 컨텍스트 내 사용자의 권한을 준수합니다.

00:06:44.680 --> 00:06:49.400
사용자가 게스트로 컨텍스트를 전환할 수는 있지만 코파일럿은 여전히 한 번에 하나의 테넌트로 범위가 제한됩니다.

00:06:49.580 --> 00:06:53.060
여러 테넌트를 하나의 지능형 작업 공간으로 병합하여 단일 답변을 제공하지는 않습니다.

00:06:53.240 --> 00:06:55.880
즉 아이디는 이동할 수 있어도 거버넌스는 이동하지 않습니다.

00:06:56.060 --> 00:07:00.800
이 둘을 분리하는 순간 경영진이 사용하는 많은 용어는 위험할 정도로 모호하게 들리기 시작합니다.

00:07:01.000 --> 00:07:04.680
연결된 테넌트 공유된 아이디 통합된 경험

00:07:04.680 --> 00:07:08.460
이러한 표현들은 협업 측면에서는 방향성이 맞을지 몰라도

00:07:08.460 --> 00:07:14.580
정책 시행 데이터 기반 확보 로깅 제어 검증이 하나의 시스템으로 작동한다는 의미와는 다릅니다.

00:07:14.800 --> 00:07:18.500
코파일럿 스튜디오 위 다중 테넌트 모드를 살펴보면 그 격차가 훨씬 더 분명해지는데

00:07:18.500 --> 00:07:21.200
프리뷰가 보여주는 내용은 매우 구체적이기 때문입니다.

00:07:21.380 --> 00:07:25.800
네, 다중 테넌트 사용은 가능하며 한 테넌트에서 호스팅된 에이전트를 다른 테넌트에서 사용할 수 있지만

00:07:25.800 --> 00:07:29.660
다중 테넌트 모드에서의 최종 사용자 인증은 아직 프리뷰에서 지원되지 않습니다.

00:07:29.840 --> 00:07:31.500
게스트 사용자는 지원되지 않습니다.

00:07:31.760 --> 00:07:33.580
사용자 지정 커넥터는 지원되지 않습니다.

00:07:33.580 --> 00:07:36.980
그래프 및 마이크로소프트 365 표준 커넥터는 지원되지 않습니다.

00:07:37.200 --> 00:07:38.840
멀티 지오는 지원되지 않습니다.

00:07:39.100 --> 00:07:40.960
일부 분석 기능은 사용할 수 없습니다.

00:07:41.300 --> 00:07:43.520
해당 모드에서는 대화 기록도 꺼져 있습니다.

00:07:43.860 --> 00:07:46.280
이는 성숙한 테넌트 간 거버넌스 체계가 아닙니다.

00:07:46.460 --> 00:07:48.540
이는 명확한 한계를 가진 제한된 프리뷰입니다.

00:07:48.740 --> 00:07:52.260
그리고 이러한 한계는 많은 리더십 팀이 스스로에게 들려주는 이야기를 깨뜨리기 때문에 중요합니다.

00:07:52.440 --> 00:07:55.080
그들은 다중 테넌트라는 말을 듣고 운영 성숙도를 가정합니다.

00:07:55.280 --> 00:07:58.460
그들의 아키텍트는 테넌트 간 이라는 말을 듣고 정책 대칭성을 가정합니다.

00:07:58.460 --> 00:08:02.180
그들의 제어팀은 동일한 공급업체 라는 말을 듣고 감사일관성을 가정합니다.

00:08:02.360 --> 00:08:08.220
그러고 나서 출시가 시작되면 사람들은 서로 다른 동작, 누락된 신호, 인증 및 분석 주변의 어색한 공백을 발견하게 됩니다.

00:08:08.400 --> 00:08:10.100
두 번째 사례를 상상해 보십시오.

00:08:10.220 --> 00:08:16.200
한 글로벌 기업이 테넌트 간 관계를 설정하고 사용자 경험이 코파일럿 사용까지 자연스럽게 확장될 것이라고 가정합니다.

00:08:16.400 --> 00:08:21.420
공유된 디렉토리 신뢰, 더 원활한 액세스, 공통 아이디 패턴을 포함하는 그 기대는 합리적으로 들립니다.

00:08:21.420 --> 00:08:25.520
하지만 팀이 실제 코파일럿 및 에이전트 시나리오를 테스트하면 동작이 일관되지 않습니다.

00:08:25.680 --> 00:08:28.080
일부 데이터는 컨텍스트를 전환했을 때만 나타납니다.

00:08:28.300 --> 00:08:30.220
일부 예상했던 커넥터는 사용할 수 없습니다.

00:08:30.500 --> 00:08:34.000
일부 감사 기대치는 프리뷰 기능이 실제로 노출하는 내용과 일치하지 않습니다.

00:08:34.200 --> 00:08:37.760
경영진은 여전히 연결됨이라고 듣는 반면 제어팀은 예외사항을 찾기 시작합니다.

00:08:37.920 --> 00:08:39.520
이는 기술적인 예외 상황이 아닙니다.

00:08:39.680 --> 00:08:41.140
거버넌스에 대한 잘못된 해석입니다.

00:08:41.380 --> 00:08:44.260
감사관은 귀하의 아키텍처에 대한 이야기가 아니라 증거를 확인하기 때문입니다.

00:08:44.260 --> 00:08:51.700
그들은 프롬프트가 어디서 실행되었는지, 어떤 테넌트가 정책을 시행했는지, 어떤 로그가 존재하는지, 그리고 연결되었다고 설명한 환경 전반에서 제어장치가 실제로 비교 가능한지를 묻습니다.

00:08:51.860 --> 00:08:55.920
귀하의 운영 모델이 아이디를 거버넌스로 취급했다면 명쾌한 답변을 내놓을 수 없을 것입니다.

00:08:56.120 --> 00:08:58.880
그러니 여기서 한 문장만 기억해야 한다면 이것을 기억하십시오.

00:08:59.000 --> 00:09:01.480
테넌트 간 아이디가 곧 테넌트 간 지능은 아닙니다.

00:09:01.660 --> 00:09:03.400
아이디는 사용자의 접속을 돕습니다.

00:09:03.400 --> 00:09:10.240
하지만 코파일럿 이 동작이 일관되게 관리되는지, 제대로 모니터링되는지, 기업이 하나의 환경이라 부르는 모든 곳에서 안전하게 확장할 수 있는지는 알려주지 않습니다.

00:09:10.400 --> 00:09:13.300
그 점이 분명해지면 더 많은 테넌트 연결이 해결책이 될 수는 없습니다.

00:09:13.560 --> 00:09:15.040
그 답은 아키텍처여야 합니다.

00:09:15.300 --> 00:09:18.180
실제로 작동하는 거버넌스 모델, 바로 허브앤스포크입니다.

00:09:18.400 --> 00:09:24.800
그렇다면 플랫폼이 파편화되어 있고 아이디가 부분적이며 테넌트 경계가 여전히 중요한 상황에서 실제 거버넌스 모델은 어떤 모습일까요?

00:09:24.980 --> 00:09:27.200
그것은 바로 허브앤스포크 시스템의 모습입니다.

00:09:27.200 --> 00:09:33.820
슬라이드 위에 도표가 깔끔해서가 아니라 여러분이 현재 마주하고 있는 복잡한 운영 상황에 실제로 부합하기 때문에 이 방식을 제안합니다.

00:09:34.000 --> 00:09:42.040
거버넌스 결정이 단일 시스템으로 설계, 측정 및 집행되는 중앙 집중식 장소가 필요하며 그러한 결정을 실행할 로컬 테넌트 팀이 필요합니다.

00:09:42.220 --> 00:09:48.800
이들 로컬팀은 압박을 느낄 때마다 자신만의 규칙을 새로 만들지 말고 정해진 경계 안에서 업무를 수행해야 합니다.

00:09:49.000 --> 00:09:50.340
허브부터 시작해야 합니다.

00:09:50.340 --> 00:09:58.180
허브는 관리자 포털이나 화려한 대시보드가 아니면 모든 테넌트에 뛰어들어 수동으로 파일을 정리하는 영웅적인 중앙팀도 결코 아닙니다.

00:09:58.340 --> 00:10:01.780
대신 허브는 최종적인 거버넌스 권한을 행사하는 역할을 합니다.

00:10:02.000 --> 00:10:07.080
이 그룹은 정책 설계, 감사 기준, 네이블 표준 및 롤아웃 기준을 책임집니다.

00:10:07.280 --> 00:10:14.100
이들이 바로 코파일럿 준비 상태의 정의, 증명으로 간주되는 근거, 보안 격차를 해결해야 하는 속도를 결정합니다.

00:10:14.340 --> 00:10:16.860
그러한 변화가 전체 대화의 흐름을 바꿉니다.

00:10:16.860 --> 00:10:23.860
이 구조 덕분에 글로벌은 마법 같은 하나의 화면을 지칭하는 단어가 아니라 반일 통합 거버넌스 시스템을 의미하게 됩니다.

00:10:24.060 --> 00:10:28.860
퍼뷰 제어, 감사 수집 방식, 민감도 레이블에 대해 각각 하나의 표준이 마련됩니다.

00:10:29.640 --> 00:10:35.040
특정 테넌트가 더 많은 사용자에게 코파일럿 액세스를 확장하기 전에 충족해야 할 명확한 기준이 존재합니다.

00:10:35.220 --> 00:10:36.820
그 다음에는 스포크가 필요합니다.

00:10:37.060 --> 00:10:41.580
스포크는 해당 기준을 가져와 각자의 특정 환경에 적용하는 로컬 테넌트 실행팀입니다.

00:10:41.800 --> 00:10:46.600
이들이 바로 수정 작업을 실행하고 로그를 검증하며 광범위한 액세스 권한을 검토하는 팀입니다.

00:10:46.600 --> 00:10:51.700
하지만 이들은 무분별한 방식이 아닌 매우 좁고 제한된 설계 공간 안에서 모든 작업을 수행합니다.

00:10:51.860 --> 00:10:55.940
로컬 팀이 계획에서 벗어나야 할 경우 예외를 위한 공식적인 경로가 마련되어 있습니다.

00:10:56.220 --> 00:11:00.260
또한 더 빠르게 움직이고 싶더라도 여전히 공통 제어 항목을 먼저 충족해야 합니다.

00:11:00.460 --> 00:11:07.780
지역적 또는 법적 차이가 발생하면 아무도 모르는 로컬 우회로에 조용히 묻히는 대신 해당 문제를 문서화하고 수인을 받아야 합니다.

00:11:08.000 --> 00:11:09.260
이 구조는 필수적입니다.

00:11:09.540 --> 00:11:15.600
완전히 중앙 집중화된 모델은 100의 현장의 세부사항을 처리하지 못하고 완전히 로컬인 모델은 거의 즉시 일관성을 잃기 때문입니다.

00:11:15.600 --> 00:11:19.220
허브 앤 스포크, 허브 앤드 스포크 방식은 이 두 가지 실패 패턴을 모두 방지합니다.

00:11:19.340 --> 00:11:24.240
허브는 필요한 일관성을 제공하고 스포크는 실제 작업이 이루어지는 현장에서 실행 속도를 높여줍니다.

00:11:24.420 --> 00:11:25.620
구체적으로 살펴보겠습니다.

00:11:26.060 --> 00:11:31.520
허브에서는 코파일럿이 확장되기 전에 모든 테넌트가 실행해야 하는 최소한의 법요, 법요, 제어세트를 정의합니다.

00:11:31.740 --> 00:11:36.320
어떤 감사 이벤트를 확인할 것인지, 그리고 얼마나 자주 검토할 것인지를 정확히 정의합니다.

00:11:36.320 --> 00:11:44.320
또한 민감한 콘텐츠를 위한 공통 레이블 분류 체계를 생성하여 기밀, 태그가 5개의 테넌트에서 서로 다르게 해석되지 않도록 합니다.

00:11:44.500 --> 00:11:51.280
전반적인 보안 상태는 매달, 롤아웃이 활발한 영역은 더 자주 검토하는 식으로 검토 주기를 설정합니다.

00:11:51.520 --> 00:11:56.500
스포크에서는 팀이 이러한 상위 수준의 표준을 해당 테넌트의 실제 상황에 맞게 적용합니다.

00:11:56.700 --> 00:12:01.400
광범위한 액세스 권한이 노출된 사이트와 레이블 지정이 뒤처진 비즈니스 부서를 찾아냅니다.

00:12:01.400 --> 00:12:05.980
감사 기능이 실제로 켜져 있는지, 그리고 보안팀이 적절한 기록을 볼 수 있는지 확인합니다.

00:12:06.120 --> 00:12:09.400
공식적으로 검토되지 않은 예외를 만든 로컬 관리자를 찾아내고,

00:12:09.900 --> 00:12:14.440
파일럿 그룹을 안전하게 확장할지 아니면 먼저 문제를 해결하고 멈춰야 할지 결정합니다.

00:12:14.640 --> 00:12:16.160
여기서 중요한 원칙이 있습니다.

00:12:16.400 --> 00:12:20.440
규칙이 없다면 이 모델은 실질적인 거버넌스가 아닌 단순한 제한에 불과하기 때문입니다.

00:12:20.620 --> 00:12:23.460
유효성이 검증된 감사 로깅, 완료된 과도한 공유 스캔,

00:12:23.520 --> 00:12:27.420
그리고 최소한의 레이블 적용 기준 없이는 어떤 테넌트에서도 코파일럿 롤아웃을 진행할 수 없습니다.

00:12:27.420 --> 00:12:30.840
단순히 계획 중이 거나 부분적으로 논의 중인 상태를 말하는 것이 아닙니다.

00:12:30.980 --> 00:12:32.340
반드시 검증되어야 합니다.

00:12:32.560 --> 00:12:36.080
테넌트가 이 세 가지 조건을 충족함을 증명하지 못하면 로라웃은 중단됩니다.

00:12:36.280 --> 00:12:39.760
AI를 통해 의도치 않게 노출된 민감한 콘텐츠를 사용자가 발견한 후

00:12:39.760 --> 00:12:43.280
이를 수습하는 엄청난 비용과 비교하면 이는 염격하게 들리지 않을 것입니다.

00:12:43.460 --> 00:12:46.700
그런 관점에서 보면 이러한 규칙은 아주 기본적인 상식입니다.

00:12:46.920 --> 00:12:49.540
이 모델이 효과적인 또 다른 이유는 타이밍 때문입니다.

00:12:49.760 --> 00:12:53.680
이를 설정하는 것을 미룰수록 나중에 스스로 해결해야 할 수습 부채가 더 늘어납니다.

00:12:53.680 --> 00:12:57.820
기준보다 앞서 로라웃을 진행하는 모든 테넌트는 결국 팀이 나중에 해결해야 할

00:12:57.820 --> 00:13:00.900
방대한 양의 예외사항과 누락된 증거 기록으로 남게 됩니다.

00:13:01.140 --> 00:13:04.600
리더들은 종종 거버넌스를 도입이 완료된 후에 성숙시킬 수 있는 것으로 여기지만

00:13:04.600 --> 00:13:08.280
멀티 테넌트 코파일럿 환경에서 그러한 순서는 완전히 거꾸로 된 것입니다.

00:13:08.460 --> 00:13:10.220
거버넌스가 로라웃을 주도해야 합니다.

00:13:10.420 --> 00:13:13.580
그렇지 않으면 로라웃은 팀이 감당할 수 있는 수준 이상의 부채를 만들게 될 것입니다.

00:13:13.760 --> 00:13:17.000
기업 차원에서 이를 이끌고 있다면 다음에 무엇을 해야 할지는 매우 명확합니다.

00:13:17.220 --> 00:13:20.120
지금 바로 허브를 구축하고 오늘 기준점을 정의하십시오.

00:13:20.120 --> 00:13:24.040
스포크를 할당하고 예외 처리 프로세스를 즉시 문서화하십시오.

00:13:24.180 --> 00:13:26.240
테넌트 자체가 하나로 움직이지 않더라도

00:13:26.240 --> 00:13:31.120
위사결정과 출시관문이 단일 시스템으로 작동하도록 글로벌 체계를 만들어야 합니다.

00:13:31.360 --> 00:13:35.040
내일 아침 무엇이 시행될지를 실제로 바꿀 때만 모델은 의미가 있습니다.

00:13:35.340 --> 00:13:37.500
리더가 확장 전에 측정해야 할 것들.

00:13:37.660 --> 00:13:41.420
거버넌스 모델은 모두가 공유하는 측정 지표를 생성할 때만 유지됩니다.

00:13:41.680 --> 00:13:44.980
그렇지 않으면 각 테넌트는 자신만의 언어로 진척도를 주장할 것이고

00:13:44.980 --> 00:13:48.460
리더십은 실질적인 통제권 없이 현황 보고만 받게 될 것입니다.

00:13:48.460 --> 00:13:54.640
코파일럿을 더 확장하기 전에 아키텍처가 의도한 대로 작동하는지 알려주는 소수의 핵심 지표가 필요합니다.

00:13:54.820 --> 00:13:59.060
활동 수준은 진실을 말해주지 않으며 도입 수치는 결코 위험을 보여주지 않습니다.

00:13:59.260 --> 00:14:01.500
과도한 공유를 줄이는 것부터 시작해야 합니다.

00:14:01.700 --> 00:14:06.040
이는 귀하의 환경이 AI를 위해 더 안전해지고 있다는 가장 확실한 신호 중 하나입니다.

00:14:06.240 --> 00:14:08.700
광범위한 액세스 그룹, 공개된 시어포인트 사이트,

00:14:09.160 --> 00:14:13.000
그리고 비즈니스 요구보다 훨씬 많은 권한을 부여하는 오래된 권한 설정을 살펴봐야 합니다.

00:14:13.000 --> 00:14:18.820
목표는 완벽한 수치를 달성하는 것이 아니라 코파일럿 위 범위가 확대되기 전에 노출 수준이 낮아지고 있음을 증명하는 것입니다.

00:14:18.960 --> 00:14:24.160
이 두 지표가 반대 방향으로 움직인다면 근본적인 문제를 해결하는 것보다 훨씬 빠르게 확장하고 있는 것입니다.

00:14:24.340 --> 00:14:27.360
두 번째로 필요한 지표는 가시성, 오브 저버빌리티, 범위입니다.

00:14:27.560 --> 00:14:32.180
실질적인 조사를 뒷받침할 수 있는 방식으로 모든 테넌트에서 코파일럿이 무엇을 하는지 실제로 볼 수 있습니까?

00:14:32.180 --> 00:14:37.220
대부분의 연구는 마이크로소프트 퍼뷰를 코파일럿 상호작용과 같은 핵심 기록이 저장되는 주요 장소로 지목하지만,

00:14:37.600 --> 00:14:39.880
이는 모든 곳에서 감사가 활성화되어 있다고 가정합니다.

00:14:40.060 --> 00:14:43.060
가시성 범위는 단순히 작동하고 있다고 가정할 수 있는 것이 아닙니다.

00:14:43.240 --> 00:14:49.020
어떤 테넌트가 감사 수집을 활성화했고, 어떤 테넌트가 여전히 부분적인 가시성만 제공하는지 정확히 알아야 합니다.

00:14:49.240 --> 00:14:51.880
로그가 없으면 거버넌스도 없고 책임도 없습니다.

00:14:52.220 --> 00:14:54.540
단호하게 들리겠지만, 그래야만 하기 때문입니다.

00:14:54.700 --> 00:14:57.140
테넌트가 무슨 일이 일어나는지에 대한 유용한 증거를 제공할 수 없다면,

00:14:57.500 --> 00:14:59.480
그 테넌트는 안전하게 확장할 준비가 되지 않은 것입니다.

00:14:59.480 --> 00:15:04.520
검사할 수 없는 것은 통제할 수 없으며, 나중에 문제가 발생했을 때 자신의 행동을 방어할 수도 없을 것입니다.

00:15:04.700 --> 00:15:07.920
세 번째 지표는 모든 테넌트의 정책이 적용되기까지 걸리는 시간입니다.

00:15:08.120 --> 00:15:12.700
여기서 리더십은 허브앤스포크 모델이 실제로 작동하는지 아니면 단지 형식뿐인지 확인하게 됩니다.

00:15:12.940 --> 00:15:18.260
한 테넌트는 이번 주에 시행하고, 다른 테넌트는 한 달 뒤에 고민한다면, 중앙의 결정은 아무런 의미가 없습니다.

00:15:18.600 --> 00:15:23.720
정책 승인 시점부터 모든 테넌트에서 해당 정책이 효과적으로 시행되기까지 걸리는 시간을 측정해야 합니다.

00:15:23.940 --> 00:15:28.480
발표하거나 문서화하는 데 걸리는 시간이 아니라, 실제로 서비스가 시작되기까지의 시간을 말하는 것입니다.

00:15:28.480 --> 00:15:32.560
이렇게 빠르게 움직이는 AI 프로그램에서 그러한 지연은 곧 위험을 의미합니다.

00:15:32.720 --> 00:15:36.760
대부분의 조직이 목표로 삼을 만한 실질적인 기준은 표준 변경 시 72시간 이내입니다.

00:15:36.960 --> 00:15:40.480
주기 시간이 그보다 훨씬 길다면 아직 확장 가능한 모델을 갖추지 못한 것입니다.

00:15:40.700 --> 00:15:43.220
단지 해결해야 할 조정 문제가 남아있는 상태인 것이죠.

00:15:43.400 --> 00:15:45.880
다음으로 확인해야 할 것은 레이블 적용 범위 비율입니다.

00:15:46.080 --> 00:15:50.200
특정 테넌트만 높은 수치를 기록하고, 나머지는 뒤처지는 허울뿐인 지표가 되게 해서는 안 됩니다.

00:15:50.500 --> 00:15:56.820
중요한 것은 민감한 콘텐츠가 사용자 추측에 의존하지 않도록 코파일럿이 일관되게 작동할 만큼 레이블이 잘 지정되어 있느냐 하는 것입니다.

00:15:56.820 --> 00:16:02.180
완벽함을 추구하라는 것이 아니라 조직 내 모든 테넌트에서 비슷한 수준의 통제력을 갖추라는 뜻입니다.

00:16:02.320 --> 00:16:05.460
마지막으로 액세스 드리프트, 액세스 드리프트 비율을 추적해야 합니다.

00:16:05.620 --> 00:16:08.960
이 지표는 정리 작업의 효과가 시간이 지나도 유지되고 있는지 알려줍니다.

00:16:09.140 --> 00:16:12.860
수정 프로젝트를 마친 후 권한이 다시 확산되기까지 얼마나 걸립니까?

00:16:13.020 --> 00:16:15.920
광범위한 그루비 시스템으로 다시 유입되는 빈도는 얼마나 됩니까?

00:16:16.120 --> 00:16:20.060
많은 팀이 수정 조치를 한 번 측정하고 문제가 영원히 사라졌다고 가정했다가 뒤늦게 깨닫곤 합니다.

00:16:20.260 --> 00:16:21.100
그렇지 않았습니다.

00:16:21.100 --> 00:16:25.280
진정으로 중요한 지표는 관리의 손길이 닿지 않을 때 시스템이 얼마나 빨리 변질되는가입니다.

00:16:25.460 --> 00:16:27.380
그것이 바로 여러분의 운영 대시보드입니다.

00:16:27.560 --> 00:16:33.460
과도한 공유 축소, 관측 가능성 범위, 정책 적용 시간, 네이블 적용 범위, 액세스 드리프트를 추적해야 합니다.

00:16:33.620 --> 00:16:36.320
보고해주기는 숫자 자체만큼이나 중요합니다.

00:16:36.560 --> 00:16:41.700
리더십은 전체 보안 상태를 한눈에 파악해야 함으로 허브가 경영진 대시보드를 관리해야 합니다.

00:16:41.900 --> 00:16:46.960
반면 실제 작업은 테넌트 경계 내에서 이루어져야 함으로 스포크가 수정 작업을 담당해야 합니다.

00:16:46.960 --> 00:16:50.200
한 팀은 시스템을 분석하고 다른 팀은 이를 바로 잡는 것입니다.

00:16:50.340 --> 00:16:53.080
확장하기 전이 아니라 사후에의 수치들을 추적해야 합니다.

00:16:53.260 --> 00:16:56.320
위험은 여러분의 다음 회의나 거버넌스, 워크숍을 기다려주지 않습니다.

00:16:56.500 --> 00:17:01.420
코파일럿이 현재의 통제 장치로 허용된 모든 것을 찾아낼 수 있는 모든 테넌트에서 이미 위험은 활성화되어 있습니다.

00:17:01.700 --> 00:17:03.800
리더들이 계속 간과하는 두 가지 패턴입니다.

00:17:04.000 --> 00:17:06.060
저는 현장에서 두 가지 특정 패턴을 계속 보는데,

00:17:06.460 --> 00:17:11.180
이는 모두 리더들이 코파일럿을 주요 통제 이벤트가 아닌 단순한 소프트웨어 출시로 다루기 때문에 발생합니다.

00:17:11.180 --> 00:17:17.600
첫 번째 패턴은 조직이 실제 퍼뷰 기준을 설정하거나 셰어포인트 액세스를 검토하기 전에 코파일럿을 배포할 때 시작됩니다.

00:17:17.800 --> 00:17:19.800
첫날의 배포 결과는 완벽해 보입니다.

00:17:20.020 --> 00:17:24.940
라이선스는 할당되었고 사용자들은 기대에 차 있으며 내부 메시지는 온통 생산성에 관한 것뿐입니다.

00:17:25.120 --> 00:17:31.720
하지만 일반적인 프롬프트가 기술적으로는 항상 접근 가능했으나 실제로는 평범한 직원의 눈에 띄지 않던 자료를 불러오기 시작합니다.

00:17:31.940 --> 00:17:38.500
AI 이전에는 아무도 보지 말아야 할 것을 찾으려고 오래된 사이트나 방치된 폴더, 상속된 권한을 일일이 클릭하며 시간을 보내지 않았습니다.

00:17:38.500 --> 00:17:44.220
하지만 이제는 그럴 필요가 없습니다. 사용자가 기본적인 질문을 하면 요약이 제공되고 파일이 나타납니다.

00:17:44.420 --> 00:17:50.060
어쩌면 인사 관련 민감한 콘텐츠 나 재무자료 또는 매우 좁은 범위 내에서만 공유되어야 할 거래 정보일 수도 있습니다.

00:17:50.260 --> 00:17:54.080
침해나 악성 코드 혹은 전통적인 의미의 보안 경계가 무너진 것은 아니었습니다.

00:17:54.440 --> 00:17:58.380
시스템은 단순히 테넌트가 이미 허용한 권한과 콘텐츠 상태를 사용했을 뿐입니다.

00:17:58.580 --> 00:18:00.920
그 순간 많은 팀이 비로소 문제를 깨닫게 됩니다.

00:18:01.220 --> 00:18:03.040
AI가 노출을 만든 것은 아닙니다.

00:18:03.240 --> 00:18:05.600
단지 그동안 노출을 숨겨주던 마찰을 제거했을 뿐입니다.

00:18:05.600 --> 00:18:09.740
한 테넌트에서 이런 일이 발생하면 조직 전체에 대한 경영진의 신뢰가 보통 하락합니다.

00:18:09.920 --> 00:18:13.400
어디서 동일한 패턴이 다시 나타날지 아무도 확신할 수 없기 때문입니다.

00:18:13.600 --> 00:18:17.080
사건은 국지적으로 보일지 몰라도 신뢰의 손상은 전사적인 것입니다.

00:18:17.260 --> 00:18:20.000
두 번째 패턴은 더 조용하지만 마찬가지로 위험합니다.

00:18:20.180 --> 00:18:24.340
회사가 테넌트 간 아이디 관계를 설정하고 멀티 테넌트 시나리오가 가능하다는 말을 들으면

00:18:24.340 --> 00:18:27.920
운영 모델이 광범위한 도입을 하기에 충분히 성숙했다고 가정합니다.

00:18:28.140 --> 00:18:30.560
발표 자료 상으로는 그럴듯한 계획처럼 들립니다.

00:18:30.860 --> 00:18:32.380
실제 운영은 복잡해집니다.

00:18:32.380 --> 00:18:35.700
한 팀은 모든 연결된 환경에서 매끄러운 코파일럿 경험을 기대하고

00:18:35.700 --> 00:18:37.640
다른 팀은 비슷한 수준의 가시성을

00:18:37.640 --> 00:18:41.500
세 번째 팀은 동일한 제어가 사용자를 따라 어디든 적용되길 기대합니다.

00:18:41.660 --> 00:18:44.880
그러면 실제 사용 과정에서 불균일 한 동작, 인증의 공백,

00:18:44.940 --> 00:18:47.200
측정 가능한 항목의 취약점이 드러나기 시작합니다.

00:18:47.420 --> 00:18:49.700
문제는 이 팀들이 부주의했다는 점이 아닙니다.

00:18:49.900 --> 00:18:52.780
진짜 문제는 이들이 연결성을 보증으로 해석했다는 것입니다.

00:18:53.000 --> 00:18:55.860
그러한 가정은 규정 준수에 관한 잘못된 이야기를 만들어냅니다.

00:18:56.080 --> 00:18:59.740
리더십은 연결되었다는 말을 듣고 조직이 준비되었다고 단정합니다.

00:18:59.740 --> 00:19:06.060
몇 달 후 제어 검토를 해보면 동작과 증거, 시행 수준이 처음에 인정하고 싶었던 것보다 훨씬 다양했다는 사실이 드러납니다.

00:19:06.240 --> 00:19:08.300
이제 이를 더 나은 패턴과 비교해 보십시오.

00:19:08.420 --> 00:19:11.300
다른 조직은 규모를 확장하기 전에 속도를 늦추는 선택을 합니다.

00:19:11.520 --> 00:19:14.920
그들은 우선 네이블 기준을 설정하고 광범위한 액세스를 먼저 검토하며

00:19:14.920 --> 00:19:17.300
다른 작업을 하기 전에 감사가시성을 검증합니다.

00:19:17.480 --> 00:19:18.920
그들은 채택을 두려워해서가 아니라

00:19:18.920 --> 00:19:22.740
다음 단계를 시작하기 전에 매 단계가 유용한 증거를 남기길 원하기 때문에

00:19:22.740 --> 00:19:24.460
순차적으로 코파일럿을 확장합니다.

00:19:24.700 --> 00:19:27.100
이런 조직은 장기적으로 더 빠르게 움직입니다.

00:19:27.100 --> 00:19:30.220
예기치 못한 상황을 설명하거나 노출된 콘텐츠를 정리하거나

00:19:30.220 --> 00:19:33.920
관리의 의미가 무엇인지 논쟁하느라 계속 멈춰 설 필요가 없기 때문입니다.

00:19:34.080 --> 00:19:36.180
그것이 대부분의 리더가 놓치고 있는 이점입니다.

00:19:36.360 --> 00:19:38.820
훌륭한 거버넌스는 여러분의 배포를 가로막지 않습니다.

00:19:39.020 --> 00:19:42.080
첫 번째 물결이 끝난 후 롤아웃 과정의 지연 요소를 제거해줍니다.

00:19:42.280 --> 00:19:43.900
함정은 도입 그 자체가 아닙니다.

00:19:44.120 --> 00:19:46.300
진정한 함정은 멀리서 보면 연결된 듯 보이지만

00:19:46.300 --> 00:19:50.180
가까이서 보면 매우 다르게 작동하는 테넌트들 사이에서 관리되지 않는 도입입니다.

00:19:50.380 --> 00:19:52.900
여러분이 내려야 할 결정은 사실 매우 간단합니다.

00:19:52.900 --> 00:19:56.400
지금 당장 연합형 허브앤스포크 AI 거버넌스 모델로 전환해야 하며

00:19:56.400 --> 00:20:00.300
테넌트별로 단순히 기능을 켜고 끄는 것을 실제 통제라고 착각해서는 안됩니다.

00:20:00.480 --> 00:20:05.080
로깅, 과도한 공유 검토, 레이블 기준 적용 범위를 증명할 수 없는 테넌트에서는

00:20:05.080 --> 00:20:06.980
코파일럿 확장을 중단해야 합니다.

00:20:07.200 --> 00:20:11.120
AI는 여러분이 보고하는 조직도가 아니라 실제로 구축한 시스템을 따를 것입니다.

00:20:11.340 --> 00:20:14.540
이 내용이 멀티테넌트 코파일럿 거버넌스에 대한 여러분의 생각을 바꾸었다면

00:20:14.540 --> 00:20:16.960
링크드인에서 저 미르코 피터스를 팔로우하시고

00:20:16.960 --> 00:20:19.580
지금 이러한 문제로 고민 중인 팀에게도 공유해주세요.