هوش ملی مصنوعی برای ایران

تعریف: ANI چت‌بات ملی نیست

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

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

چرا کشور به لایه هوش حاکمیتی نیاز دارد

کشورهایی که فقط مصرف‌کننده رابط برنامه‌نویسی خارجی می‌مانند، در سه نقطه آسیب‌پذیر می‌شوند: هزینه، دسترسی و هویت داده. هزینه می‌تواند با افزایش مصرف بالا برود؛ دسترسی می‌تواند با سیاست خارجی یا محدودیت ارائه‌دهنده قطع شود؛ و هویت داده می‌تواند در مدل‌هایی گم شود که برای زمینه فارسی، قانون محلی، فرهنگ اداری و نیازهای واقعی ایران ساخته نشده‌اند. ANI پاسخ به این وابستگی است، نه با شعار استقلال مطلق، بلکه با معماری واقع‌بینانه‌ای که استفاده از فناوری جهانی را با کنترل محلی ترکیب کند.

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

معماری پنج‌لایه ANI

معماری پیشنهادی پنج لایه دارد. لایه اول زیرساخت است: دیتاسنتر محلی، GPU، ذخیره‌سازی، شبکه، لبه شبکه و مانیتورینگ. لایه دوم داده است: پیکره داده فارسی، داده سازمانی، داده عمومی مجاز، داده عملیاتی و خط پردازش پاک‌سازی/برچسب‌گذاری. لایه سوم مدل است: مدل‌های فارسی عمومی، مدل‌های تخصصی کوچک‌تر، بازیابی، گفتار و بینایی ماشین. لایه چهارم حافظه و ابزار است: CognitivX برای زمینه و حافظه، ابزارهای سازمانی، رابط برنامه‌نویسی، خط‌مشی و ممیزی. لایه پنجم کاربردهاست: خدمات عمومی، پشتیبانی، آموزش، کشاورزی، سلامت غیرحساس، فروشگاه، مالی و کسب‌وکار.

مزیت آپالکسا در این معماری این است که ANI را از سطح مدل جدا می‌کند و آن را به محصول، حافظه، عملیات و رابط برنامه‌نویسی وصل می‌کند. Aira سطح تعامل فارسی را می‌دهد. CognitivX زمینه و حافظه را می‌دهد. بارکد، Aira پشتیبانی، Aira فروش، Socheli و محصولات دیگر سطح تعاملهای واقعی استفاده‌اند. این یعنی ANI فقط پژوهش نیست؛ می‌تواند از همان ابتدا در جریان‌های کاری محدود و قابل سنجش وارد شود.

خدمت فهرست خدمات و مرزبندی دامنه‌های ملی

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

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

نسخه عمومی می‌تواند فهرست خدمات سطح بالا و نمونه‌های کم‌ریسک را منتشر کند. نسخه خصوصی باید دامنه تخصصی خطر ماتریس، مالکها، پایلوت آمادگی، ممنوع دامنه‌ها، نیروی انسانی، KPI و وابستگیهای زیرساختی را نگه دارد. این بخش به سرمایه‌گذار نشان می‌دهد ANI فقط شعار ملی نیست؛ سبد پروژه سرویس قابل مدیریت است.

ملی تعامل‌پذیری قراردادها و استاندارد تبادل داده

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

تعامل‌پذیری قرارداد باید از رابط برنامه‌نویسی و فایل فراتر برود. باید شامل هویت، رضایت، ممیزی id، خطا کد، دوره نگهداری، هدف محدودیت و مدل اصلاح داده باشد. اگر یک سرویس عمومی به پایگاه دانش سازمانی، سیستم نوبت‌دهی، نقشه شهری یا داده کشاورزی وصل می‌شود، باید بداند داده مرجع معتبر کدام است و وقتی داده غلط بود چه مسیر اعتراض/اصلاح یا اصلاح وجود دارد. بدون این قراردادها، ANI پاسخ می‌دهد اما مسئولیت داده روشن نیست.

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

عمومی هوش مصنوعی سواد کاربردی، مدنی-خدمت آموزش مدل و پذیرش برنامه آموزشی

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

مدنی-خدمت آموزش مدل باید برای نقش‌های مختلف طراحی شود: مدیر، اپراتور، کارشناس داده، کارمند خط مقدم، تیم IT، تیم حقوقی و واحد ارتباط با مردم. هر نقش باید برنامه آموزشی خودش را داشته باشد: استفاده امن، حریم خصوصی، دستور مناسب، تفسیر خروجی، اعتراض/اصلاح مدیریت و رخداد ارجاع. اگر آموزش نباشد، ANI یا بیش از حد استفاده می‌شود یا از ترس خطا کنار گذاشته می‌شود.

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

ملی use-مورد ثبت درخواست و خرید سازمانی نردبان

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

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

نسخه عمومی می‌تواند نشان دهد آپالکسا use-موردها را با ارزیابی، پایلوت و KPI جلو می‌برد. نسخه خصوصی باید ذی‌نفع نقشه، فهرست سازمان‌ها، بودجه احتمالی، کارت امتیاز use-مورد، خرید سازمانی مسیر، معیارهای رد/قبول و قالب قرارداد را نگه دارد. این بخش مخصوص سرمایه‌گذار مهم است چون خط پردازش را از بینایی ماشین جدا می‌کند.

ملی داده اعتماد و ایمن-دسترسی محیط ایزوله برای داده‌های عمومی

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

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

نسخه عمومی می‌تواند اصل داده اعتماد، دسترسی امن، ممیزی و عدم تمرکز خام داده را توضیح دهد. نسخه خصوصی باید داده-مالک نقشه، دسترسی سطح‌ها، محیط ایزوله معماری، حقوقی قالب‌ها، دوره نگهداری قوانین، دفتر خطرها و هزینه عملیاتی اعتماد را نگه دارد. این بخش برای سرمایه‌گذار و شریک عمومی مهم است چون بدون چارچوب داده، ANI نه قابل اتکا می‌شود و نه قابل دفاع.

اکوسیستم تامین، تامین‌کننده بی‌طرفی و توانمندی محلی

ANI اگر به یک تامین‌کننده، یک مدل یا یک دیتاسنتر قفل شود، از نظر راهبردی شکننده می‌شود. برنامه باید تامین‌کننده-بی‌طرف باشد: مدل‌های مختلف، ارائه‌دهنده‌های مختلف، سخت‌افزارهای مختلف و مسیرهای استقرار متفاوت باید بتوانند پشت یک خط‌مشی، دروازه کنترل و ارزیابی مشترک کار کنند. این به معنای بی‌نظمی نیست؛ یعنی کنترل لایه کنترل آپالکسا باید انتخاب مدل و زیرساخت را با معیار کیفیت، هزینه، حاکمیت داده و ریسک انجام دهد.

بخش مهم دیگر توانمندی محلی است. ANI فقط با خرید رابط برنامه‌نویسی یا GPU ساخته نمی‌شود؛ باید تیم‌های محلی توانایی داده، ارزیابی، امنیت، عملیات، UI فارسی، یکپارچه‌سازی و پشتیبانی را یاد بگیرند. هر پایلوت باید به انتقال دانش تبدیل شود: راهنمای عملیات رخداد، آموزش مدل، مستندسازی، خطا طبقه‌بندی، نمای مدیریتی و گزارش پس از رخداد. اگر دانش فقط نزد تامین‌کننده بیرونی بماند، پروژه ملی از نظر عملیاتی بالغ نمی‌شود.

نسخه عمومی می‌تواند از اکوسیستم باز، چندلایه و قابل ممیزی حرف بزند. نسخه خصوصی باید تامین‌کننده ماتریس، مدل‌های منتخب، هزینه هر گزینه، ریسک تامین، برنامه آموزش تیم، قرارداد پشتیبانی و معیارها انتخاب/تعویض ارائه‌دهنده را نگه دارد.

پورتال‌های ANI: عمومی، سرمایه‌گذار، شریک، ادمین

ANI اگر قرار است روی وب عمومی آپالکسا معرفی شود، نباید همه چیز در یک صفحه قرار بگیرد. سطح عمومی باید تز، معماری سطح بالا، پایلوت‌های غیرحساس، اصول داده، تصاویر و منابع پژوهشی را نشان دهد. سطح سرمایه‌گذار اتاق باید با دسترسی محدود، یادداشت مالی، فازبندی، بودجه، مشتریان بالقوه، ریسک‌ها، و سناریوهای درآمد را ارائه کند. سطح شریک درگاه باید برای سازمان یا شریک، ثبت علاقه، نوع داده، درخواست پایلوت، توافق محرمانگی، فرم نیازسنجی و وضعیت بررسی را مدیریت کند. سطح ادمین باید خط پردازش فرصت‌ها، داده‌ها، پایلوت‌ها، قراردادها، ریسک‌ها و KPIها را نگه دارد.

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

پیشنهاد عملی این است: فاز اول بدون کاربر مدیریت سنگین، با صفحات عمومی و سرمایه‌گذار فایل PDF/خصوصی پیوند شروع شود. فاز دوم با شریک ثبت درخواست و ادمین نمای مدیریتی سبک ادامه پیدا کند. فاز سوم وقتی چند پایلوت واقعی وجود دارد، نقش‌محور درگاه، اتاق داده، قرارداد ردیاب و KPI نمای مدیریتی بسازد. نسخه عمومی باید فقط این مدل لایه‌ای را نشان دهد؛ نسخه خصوصی باید طرحواره، احراز هویت، نقش‌ها، مجوزها، CRM، داده‌های سرمایه‌گذار و لیست سازمان‌ها را نگه دارد.

پایلوت‌ها: از خدمات کم‌ریسک شروع کنیم

شروع ANI نباید در حساس‌ترین حوزه‌ها باشد. مسیر بهتر، پایلوت‌های کم‌ریسک و پرکاربرد است: راهنمای خدمات عمومی، خلاصه‌سازی و دسته‌بندی مکاتبات غیرمحرمانه، پشتیبانی فارسی برای کسب‌وکارهای کوچک، دستیار کشاورزی عمومی، جست‌وجوی اسناد آموزشی، و ابزارهای داخلی سازمانی که تحت نظارت انسان کار می‌کنند. هر پایلوت باید معیار موفقیت داشته باشد: کاهش زمان پاسخ، افزایش دقت، کاهش هزینه، رضایت کاربر، نرخ هذیان مدل، و کیفیت فارسی.

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

شهروند بازخورد، اعتراض‌ها و اعتماد عمومی

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

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

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

شفافیت نمای مدیریتی و مستقل ممیزی آهنگ پیگیری

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

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

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

مستقل نظارت هیات راهبری و عمومی پاسخگویی سازوکار

برای ANI، شفافیت کافی نیست؛ باید سازوکار پاسخ‌گویی مستقل هم وجود داشته باشد. اگر برنامه به خدمات عمومی، داده سازمانی، کشاورزی، آموزش یا ابزارهای شهری نزدیک شود، تصمیم‌های کیفیت، داده، ایمنی و اولویت پایلوت نباید فقط در تیم سازنده بماند. یک نظارت هیات راهبری سبک و مرحله‌ای می‌تواند نقش مشورتی و ممیزی داشته باشد: متخصص هوش مصنوعی، حقوق داده، زبان فارسی، امنیت، نماینده صنعت، دانشگاه و در صورت حساس شدن پایلوت، نماینده ذی‌نفعان عمومی.

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

نسخه عمومی می‌تواند اصل نظارت مستقل، گزارش‌پذیری و مکانیزم اعتراض/بازبینی را منتشر کند. نسخه خصوصی باید نام افراد احتمالی، منشور دقیق، تعارض-مورد توجه قوانین، دسترسی خط‌مشی، گزارش‌های واقعی، ریسک‌های حقوقی و تصمیم‌های توقف/ادامه پایلوت را نگه دارد. این بخش کمک می‌کند ANI به جای پروژه تکنولوژیک بسته، برنامه‌ای با اعتماد اجتماعی و پاسخ‌گویی قابل دفاع باشد.

سبد پایلوت و داشبورد KPI

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

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

نسخه عمومی می‌تواند چارچوب KPI را منتشر کند. نسخه خصوصی باید اعداد پایلوت، نام شرکا، هزینه، ضعف‌ها، تصمیم ادامه/توقف و مسیر قرارداد بعدی را نگه دارد.

مدل اقتصادی و سرمایه‌گذاری

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

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

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

ANI اگر به زبان ملی یا عمومی معرفی شود، باید نشان دهد ارزش عمومی چگونه اندازه‌گیری می‌شود. مزایا دفتر ثبت یعنی هر پایلوت فقط با تعداد کاربر یا تعداد پاسخ سنجیده نشود؛ باید خط پایه، هزینه، زمان ذخیره‌شده، خطای کم‌شده، رضایت، ارجاع به انسان، شکایت، رخداد، مصرف توان محاسباتی و اثر روی نیروی انسانی ثبت شود. بدون این دفتر ثبت، برنامه می‌تواند با گزارش‌های تبلیغاتی بزرگ شود اما نداند واقعاً ارزش ساخته یا فقط هزینه جدید ایجاد کرده است.

عمومی ارزش حسابداری باید ضد اتلاف هم باشد. هر پایلوت باید خروج معیارها داشته باشد: اگر کیفیت فارسی به آستانه نرسید، اگر هزینه استنتاج از ارزش بیشتر شد، اگر داده مجاز آماده نبود، اگر اپراتورها پذیرش نداشتند، یا اگر ریسک اجتماعی بالا رفت، پروژه باید توقف موقت یا بازطراحی شود. ضداتلاف کنترل شامل فازبندی کوچک، قراردادهای نقطه عطف-مبتنی، تامین‌کننده-بی‌طرف معماری، استفاده مجدد الزام‌آور، گزارش پس از رخداد عمومی در حد امن، و جلوگیری از قفل-in به یک مدل یا تامین‌کننده است.

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

مشارکت عمومی-خصوصی، خرید سازمانی و مشتری لنگر

ANI در عمل با یک قرارداد مصرفی ساده شروع نمی‌شود؛ به مدل شراکت و خرید سازمانی نیاز دارد. بعضی پایلوت‌ها می‌توانند کسب‌وکار به کسب‌وکار مستقیم باشند، بعضی عمومی-خصوصی مشارکت، بعضی قرارداد پژوهشی/دانشگاهی، بعضی با اپراتور یا دیتاسنتر، و بعضی با سازمانی که مشتری لنگر می‌شود. هر مدل خرید، خرید سازمانی چرخه، ریسک سیاسی/حقوقی، مالکیت داده و شکل درآمد متفاوت دارد.

مشتری لنگر باید فقط نام بزرگ نباشد؛ باید بارکاری واقعی، داده مجاز، حامی داخلی داخلی، بودجه پایلوت و معیار موفقیت داشته باشد. بدون مشتری لنگر، ANI هزینه پژوهش می‌شود. با مشتری لنگر درست، هر پایلوت می‌تواند به مورد مطالعه، مجموعه‌داده مجاز، سرویس قابل تکرار و قرارداد چندساله تبدیل شود. آپالکسا باید از اول بداند کدام خدمت فهرست خدمات مورد به کدام مشتری لنگر می‌خورد و چه کسی هزینه ادامه آن را می‌دهد.

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

استانی استقرار راهنمای اجرا و مالکیت سرویس محلی

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

مالکیت محلی به معنای رها کردن حاکمیت نیست. هر سرویس منطقه‌ای باید خدمت مالک، داده متولی، رخداد تماس، ارجاع، KPI و بودجه داشته باشد، اما خط‌مشی، ممیزی و ارزیابی زیر کنترل لایه کنترل مشترک بماند. اگر منطقه‌ای پایلوت موفق دارد، قالب آن می‌تواند برای مناطق دیگر استفاده مجدد شود؛ اگر شکست خورد، گزارش پس از رخداد باید به برنامه دفتر کار برگردد. این چرخه هم یادگیری ملی می‌سازد و هم جلوی پروژه‌های پراکنده را می‌گیرد.

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

منطقه‌ای ظرفیت نقشه و اتصال به دیتاسنترهای شهرها

ANI اگر به سرویس واقعی تبدیل شود، به توان محاسباتی، ذخیره‌سازی و پشتیبانی منطقه‌ای نیاز دارد. همه بارکاریها لازم نیست در هر شهر اجرا شوند، اما برنامه باید بداند کدام سرویس به تاخیر پایین، محلی‌ماندن داده، GPU نزدیک، ذخیره‌سازی محلی، لبه شبکه دستگاه یا پشتیبانی عملیاتی نیاز دارد. یک راهنمای خدمات عمومی شاید در ابر مرکزی کافی باشد؛ اما سرویس شهری، کشاورزی، صنعت، آموزش محلی یا پردازش صوت/تصویر ممکن است از ظرفیت منطقه‌ای سود ببرد.

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

نسخه عمومی می‌تواند از ظرفیت منطقه‌ای، تاخیر، حاکمیت داده و توسعه شهرها حرف بزند. نسخه خصوصی باید مکان‌ها، ظرفیت GPU/ذخیره‌سازی، قرارداد انرژی/فیبر، مشتری لنگر تقاضا، هزینه هزینه سرمایه‌ای/عملیاتی، ریسک امنیتی و نقشه توسعه را نگه دارد. این بخش حساس است و نباید با جزئیات مکانی یا ظرفیت واقعی عمومی شود.

مدل دروازه کنترل، خدمت دفتر ثبت و ممیزی اتوبوس

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

این لایه تامین جلوی پراکندگی پایلوت‌ها را می‌گیرد. اگر هر پایلوت مدل، ثبت رخداد، مجوز و نمای مدیریتی خودش را بسازد، ANI بعد از چند پروژه به مجموعه‌ای از نمایش اولیههای غیرقابل اداره تبدیل می‌شود. دروازه و دفتر ثبت اجازه می‌دهند پایلوت‌ها متفاوت باشند اما حاکمیت، پایش، هزینه انتساب و انتشار نسخه نظم مهندسی مشترک بماند. همین نقطه اتصال به رابط برنامه‌نویسی/پروتکل‌محور و انسانی-کنترل‌شده اتوماسیون است.

نسخه عمومی می‌تواند از معماری مشترک، دفتر ثبت سرویس‌ها و ممیزی صحبت کند. نسخه خصوصی باید دروازه کنترل طراحی، مسیریابی خط‌مشی، مدل دفتر ثبت، ممیزی طرحواره، هزینه انتساب، محیط مشتری جداسازی، کلید نگهداشت کلید/داده و راهنمای عملیات رخدادهای عملیاتی را نگه دارد. این بخش برای سرمایه‌گذار مهم است چون نشان می‌دهد ANI فقط روایت نیست؛ کنترل لایه کنترل قابل ساخت دارد.

حاکمیت، مالکیت و قرارداد داده

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

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

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

ارزیابی ANI: کیفیت فارسی، ایمنی و اثر اقتصادی

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

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

اثر اقتصادی هم باید ارزیابی شود: کاهش زمان پاسخ، کاهش هزینه پشتیبانی، افزایش نرخ حل مسئله، کاهش خطای انسانی، کاهش زمان جست‌وجوی سند، و تبدیل فرایند دستی به ابزار قابل ممیزی. این اعداد در نسخه عمومی می‌توانند به شکل چارچوب منتشر شوند؛ اما مقدار واقعی هر پایلوت، خطاها، ضعف‌ها و هزینه‌ها باید خصوصی بماند تا قبل از بلوغ محصول به ریسک اعتباری تبدیل نشود.

آزمون تیم قرمز ملی، عمومی رخداد پروتکل و توقف پایلوت

ANI اگر وارد کاربردهای عمومی یا سازمانی جدی شود، باید آزمون تهاجمی منظم داشته باشد. تست‌ها فقط نباید دستورهای بد باشند؛ باید سناریوهای عملیاتی را بسنجند: پاسخ غلط در خدمات عمومی، افشای داده، تبعیض زبانی یا منطقه‌ای، توصیه حساس، ابزار اقدام اشتباه، دور زدن مجوز، هذیان مدل در متن اداری، یا هزینه استنتاج غیرعادی. هر خدمت فهرست خدمات مورد باید تهدید سناریوها خودش را داشته باشد.

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

صفحه عمومی می‌تواند از ارزیابی ایمنی، آزمون تهاجمی و شفافیت مسئولانه حرف بزند. نسخه خصوصی باید موارد آزمون، سوءاستفادهها، آستانه‌ها توقف، رخداد مخاطبان/تماس‌ها، اعلان قالب‌ها، حقوقی بازبینی، نتایج آزمون تهاجمی و خطر پذیرش هر شریک را نگه دارد. این بخش برای جدی بودن ANI ضروری است.

مدل حاکمیت چندذی‌نفعی

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

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

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

ANI برنامه دفتر خطرها، وابستگی هیات راهبری و پارلمانی/عمومی گزارش توجیهی بسته

برنامه ANI اگر جدی شود، باید دفتر خطرها زنده داشته باشد: داده، امنیت، انرژی، تامین GPU، کیفیت فارسی، اعتماد عمومی، خرید سازمانی، تامین‌کننده قفل-in، رخداد، سوءاستفاده، هزینه عملیاتی و شکست پذیرش. وابستگی هیات راهبری باید نشان دهد کدام ریسک به دیتاسنتر، مدل فارسی، داده اعتماد، آموزش، قانون یا شریک خاص وابسته است. بدون این هیات راهبری، برنامه بزرگ به مجموعه‌ای از پایلوت‌های جدا تبدیل می‌شود.

عمومی گزارش توجیهی بسته باید برای ذی‌نفعان غیرتکنیکی آماده باشد: هدف برنامه، محدودیت‌ها، پایلوتهای کم‌ریسک، روش ممیزی، مسیر بازخورد، هزینه/فایده، و چیزهایی که عمداً انجام نمی‌شود. اگر قرار است ANI اعتماد عمومی بسازد، باید بتواند به زبان ساده توضیح دهد چرا این برنامه چت‌بات تبلیغاتی نیست و چگونه جلوی اتلاف، سوءاستفاده و قفل‌شدن به تامین‌کننده گرفته می‌شود.

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

دفتر برنامه ANI و ریتم اجرایی

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

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

برای سرمایه‌گذار، دفتر برنامه نشان می‌دهد ANI قابل مدیریت است. برای شریک سازمانی، نشان می‌دهد پروژه فقط پژوهش نیست و مسئولیت دارد. برای سایت عمومی، کافی است بگوییم آپالکسا ANI را با پایلوت، ممیزی و KPI پیش می‌برد. نسخه خصوصی باید ماتریس مسئولیت، بودجه تیم، آهنگ پیگیری، نمای مدیریتی، قراردادها، تامین‌کنندهها و برنامه استخدام را نگه دارد.

نقشه اجرا: از تز عمومی تا عملیاتی برنامه

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

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

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

مرز انتشار عمومی و محرمانگی

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

ANI باید از همان ابتدا دو نسخه داشته باشد: نسخه عمومی تز برای وب و رسانه؛ نسخه سرمایه‌گذار/حاکمیت یادداشت برای جلسه‌های جدی؛ و نسخه داخلی عملیاتی مشخصات برای اجرا. سایت باید هر سه را پشتیبانی کند، اما همه چیز نباید عمومی نمایه‌شده باشد.