حاکمیت و انطباق۶ دقیقه مطالعه

از کجا بفهمیم پروژه‌ی هوش مصنوعی‌مان جلوی حسابرس دفاع‌پذیر است

حسابرس نمی‌پرسد مدلتان چقدر هوشمند است. می‌پرسد چطور تصمیم گرفتید، چه کسی تأیید کرد، و کجا نوشته شده.

یک الگوی تکرارشونده در پروژه‌های سازمانی هست که تقریباً همیشه به یک شکل تمام می‌شود.

تیم فنی شش ماه کار می‌کند. سامانه راه می‌افتد و خوب هم کار می‌کند. بعد واحد حسابرسی داخلی یا یک نهاد ناظر سؤال می‌پرسد، و معلوم می‌شود هیچ‌کس نمی‌تواند به سؤال‌ها جواب بدهد. نه چون کار بد بوده — چون چیزی نوشته نشده.

بعد سه ماه صرف بازسازی مستنداتی می‌شود که اگر از روز اول نوشته می‌شدند، در مجموع سه روز وقت می‌بردند.

این مقاله درباره‌ی همان سه روز است.

حسابرس واقعاً چه می‌پرسد

اولین سوءتفاهم رایج این است که فکر می‌کنیم حسابرس می‌خواهد بفهمد مدل چطور کار می‌کند. نمی‌خواهد. در بیشتر موارد اصلاً تخصص فنی‌اش را ندارد و لازم هم نیست داشته باشد.

آنچه می‌خواهد بفهمد این است: آیا این تصمیم قابل ردیابی است؟

یعنی: چه کسی تصمیم گرفت این کار با هوش مصنوعی انجام شود؟ بر چه اساسی؟ چه گزینه‌هایی بررسی شد؟ چه ریسک‌هایی شناسایی شد و برای هرکدام چه کنترلی گذاشته شد؟ چه کسی تأیید کرد؟ و اگر فردا خروجی اشتباهی تولید شود، چطور می‌فهمید و چه می‌کنید؟

هیچ‌کدام از این‌ها سؤال فنی نیست. همه‌شان سؤال حاکمیتی‌اند.

هفت چیزی که باید داشته باشید

بر اساس کارهایی که تا حالا انجام داده‌ام، این هفت مورد تقریباً همیشه خواسته می‌شوند. ترتیبشان هم به‌ترتیب دفعاتی است که نبودشان مشکل ساخته.

۱. سیاست‌نامه‌ی مکتوب

سندی که می‌گوید در این سازمان استفاده از هوش مصنوعی چه حدودی دارد. لازم نیست بلند باشد. یک صفحه که سه چیز را روشن بگوید کافی است: چه کسی تأیید می‌کند، چه داده‌ای هرگز نباید وارد ابزار بیرونی شود، و کدام دسته تصمیم‌ها حتماً تأیید انسانی می‌خواهند.

سیاست‌نامه‌ی یک‌صفحه‌ای که اجرا می‌شود، بی‌نهایت از سند سی‌صفحه‌ای که کسی نخوانده بهتر است.

۲. طبقه‌بندی داده

باید بتوانید نشان بدهید می‌دانید چه داده‌ای در این فرآیند درگیر است و در چه سطحی از حساسیت قرار دارد. اگر داده‌ی تنظیم‌شده درگیر است، باید نشان بدهید کجا پردازش می‌شود و چه کسی دسترسی دارد.

این معمولاً اولین جایی است که پروژه‌ها می‌لنگند. نه چون کار سختی است — چون کسی زحمتش را نکشیده.

۳. ثبت تصمیم معماری

چرا این معماری انتخاب شد؟ چه گزینه‌هایی بررسی شدند؟ چرا رد شدند؟

این سند در زمان تصمیم‌گیری نوشتنش ده دقیقه وقت می‌برد. شش ماه بعد بازسازی‌اش تقریباً غیرممکن است، چون کسی دقیقاً یادش نیست چرا آن‌طور تصمیم گرفتند.

۴. مجموعه‌ی ارزیابی و عددش

باید بتوانید بگویید کیفیت خروجی چقدر است و این عدد چطور به‌دست آمده. «روی چند نمونه؟ نمونه‌ها از کجا آمدند؟ آیا همان نمونه‌هایی بودند که برای ساختن استفاده شدند؟»

اگر جواب سؤال آخر بله باشد، عدد بی‌اعتبار است. این را حسابرس هم می‌داند.

۵. کارت سیستم

یک صفحه که می‌گوید سیستم چه می‌کند، چه نمی‌کند، روی چه داده‌ای سنجیده شده، با چه معیار و چه عددی، چه محدودیتی باقی مانده، و چه کاری هنوز انسان انجام می‌دهد.

من هیچ پروژه‌ای را بدون این سند تمام نمی‌کنم. نه به‌خاطر حسابرس — به‌خاطر خود سازمان. شش ماه بعد که تیم عوض شده باشد، این تنها سندی است که می‌گوید این سامانه قرار بود چه کار کند.

۶. لاگ

بدون لاگ ورودی و خروجی، هیچ ادعایی درباره‌ی رفتار سامانه قابل راستی‌آزمایی نیست. اگر کسی بگوید «سامانه پاسخ اشتباه داد»، بدون لاگ نمی‌توانید نه تأییدش کنید نه ردش.

نکته‌ی مهم: لاگ باید به‌ازای واحد تفکیک‌پذیر باشد. لاگ درهم‌ریخته‌ی همه‌ی سازمان، در عمل قابل استفاده نیست.

۷. رویه‌ی انسان در حلقه

برای کدام تصمیم‌ها تأیید انسانی لازم است؟ چه کسی تأیید می‌کند؟ و آیا هویت تأییدکننده ثبت می‌شود؟

بند سوم را معمولاً فراموش می‌کنند. رویه‌ای که ثبت نمی‌شود، از نظر حسابرس وجود ندارد.

چرا بعد از استقرار گران‌تر است

سه دلیل ساده.

اول، حافظه. تصمیم‌هایی که در جلسه گرفته شدند، شش ماه بعد دقیق یادتان نیست. بازسازی‌شان تبدیل می‌شود به حدس‌زدن.

دوم، افراد. کسی که آن تصمیم را گرفت ممکن است دیگر در سازمان نباشد.

سوم، و مهم‌تر از هر دو: بعضی مستندات را اصلاً نمی‌شود عطف به ماسبق نوشت. مجموعه‌ی ارزیابی که بعد از استقرار ساخته شود، ناخودآگاه از موارد شکست‌خورده‌ای که دیده‌اید ساخته می‌شود. این دیگر ارزیابی مستقل نیست.

معیار پذیرش هم همین‌طور. عددی که بعد از دیدن نتیجه توافق شود، معیار پذیرش نیست؛ توجیه است.

نسبتش با استانداردها

اگر سازمانتان به سمت ISO/IEC 42001 می‌رود یا از چارچوب NIST AI RMF استفاده می‌کند، این هفت مورد تقریباً همگی زیرمجموعه‌ی الزامات آن‌ها هستند.

ولی ترتیب کار مهم است. سازمان‌هایی که از استاندارد شروع می‌کنند معمولاً در بند اول گیر می‌کنند و پروژه متوقف می‌شود. سازمان‌هایی که از این هفت مورد عملی شروع می‌کنند، وقتی به استاندارد برسند می‌بینند بخش بزرگی از کار انجام شده.

استاندارد را به‌عنوان چک‌لیست پایانی استفاده کنید، نه به‌عنوان نقطه‌ی شروع.

چطور این هفت مورد را در سه روز جمع کنید

اگر پروژه‌ای دارید که مستندش نیست، این ترتیب در عمل جواب می‌دهد. فرض بر این است که سامانه کار می‌کند و فقط سند ندارد.

روز اول — جلسه‌ی بازسازی تصمیم. هر کسی که در تصمیم‌های اصلی نقش داشته را در یک اتاق جمع کنید، حداکثر دو ساعت. فقط چهار سؤال بپرسید: چه گزینه‌هایی روی میز بود، چرا این یکی انتخاب شد، چه چیزی نگرانتان بود، و برای آن نگرانی چه کردید.

یادداشت این جلسه، نود درصد ثبت تصمیم معماری شماست. اگر شش ماه صبر کنید، همین جلسه دیگر نتیجه نمی‌دهد چون کسی دقیق یادش نیست.

روز دوم — طبقه‌بندی داده و کارت سیستم. فهرست کنید چه داده‌ای وارد سامانه می‌شود، از کجا می‌آید، کجا پردازش می‌شود و چه کسی دسترسی دارد. بعد کارت سیستم را بنویسید. کارت سیستم اگر صادقانه نوشته شود، معمولاً یک بعدازظهر وقت می‌برد.

سخت‌ترین بخش کارت سیستم، بند «چه نمی‌کند» است. اگر نوشتنش برایتان سخت بود، نشانه‌ی خوبی است — یعنی دارید واقعاً فکر می‌کنید، نه اینکه فرم پر می‌کنید.

روز سوم — مجموعه‌ی ارزیابی و رویه‌ها. بیست تا پنجاه نمونه‌ی واقعی جمع کنید و پاسخ درستشان را بنویسید. بعد رویه‌ی انسان در حلقه و سیاست‌نامه‌ی یک‌صفحه‌ای را بنویسید.

اینجا یک صداقت لازم است: مجموعه‌ی ارزیابی که امروز می‌سازید، اعتبار مجموعه‌ای که پیش از شروع ساخته می‌شد را ندارد. در سند بنویسید که این مجموعه پس از استقرار ساخته شده. حسابرسی که ببیند این را خودتان نوشته‌اید، بیشتر به بقیه‌ی سند اعتماد می‌کند.

دو سؤالی که معمولاً غافلگیر می‌کنند

«اگر این سامانه فردا از کار بیفتد، چه می‌شود؟»

این سؤال درباره‌ی هوش مصنوعی نیست؛ درباره‌ی وابستگی عملیاتی است. اگر جواب این باشد که کار متوقف می‌شود و مسیر دستی جایگزینی وجود ندارد، شما یک ریسک تداوم کسب‌وکار ساخته‌اید که در ارزیابی اولیه دیده نشده بود.

مسیر دستی جایگزین را مستند کنید، حتی اگر کند باشد.

«چه کسی متوجه می‌شود اگر کیفیت خروجی به‌مرور افت کند؟»

سامانه‌ای که روز اول خوب کار می‌کند، لزوماً شش ماه بعد هم خوب کار نمی‌کند. جنس ورودی‌ها عوض می‌شود، ابزار پشت صحنه به‌روز می‌شود، و کسی خبردار نمی‌شود.

جواب قابل قبول این است: «مجموعه‌ی ارزیابی هر فصل دوباره اجرا می‌شود و اگر نمره از آستانه‌ی مشخصی پایین‌تر بیاید، هشدار داده می‌شود.» اگر چنین رویه‌ای ندارید، این احتمالاً مهم‌ترین شکاف شماست.

آنچه این مقاله نمی‌گوید

این فهرست جایگزین مشورت با واحد حقوقی یا انطباق سازمان شما نیست. صنایع مختلف الزامات متفاوتی دارند و من ادعا نمی‌کنم همه‌شان را می‌شناسم.

همچنین داشتن این هفت مورد تضمین نمی‌کند که در ممیزی قبول شوید. تضمین می‌کند که سؤال‌ها را بفهمید و جوابی برای گفتن داشته باشید — که در عمل تفاوت اصلی است.

اقدام مشخص

یکی از پروژه‌های در حال اجرایتان را انتخاب کنید و این هفت مورد را روی کاغذ علامت بزنید: کدام را دارید، کدام را ندارید.

اگر بیش از سه مورد را ندارید، پیش از اضافه‌کردن هر قابلیت جدید، سراغ همان‌ها بروید. کارِ نیمه‌مستند که ادامه پیدا کند، فقط بدهی‌اش بزرگ‌تر می‌شود.

اگر می‌خواهید نقطه‌ی شروع دقیق‌تری داشته باشید، خودارزیابی بلوغ این سایت همین محورها را در پانزده سؤال می‌سنجد و سه شکاف اصلی‌تان را به‌ترتیب اولویت نشان می‌دهد.

می‌خواهید همین را روی کار خودتان پیاده کنید؟

همین‌جا پاسخ دهید و پتانسیل اتوماسیون کسب‌وکارتان را بسنجید.

یک جلسه‌ی نیم‌ساعته کافی است تا بفهمیم این موضوع کجای کار شما می‌نشیند.

اگر این خدمات مناسب شما نباشد، صریحاً به شما می‌گویم.