دادهی تنظیمشده
هوش مصنوعی در بانک و بیمه
در بانک و بیمه، مسئله هیچوقت «آیا این کار قابل خودکارسازی است» نیست. مسئله این است که آیا میشود خودکارش کرد و همزمان جلوی بازرس بانک مرکزی و حسابرس داخلی دفاعش کرد.
سطح دادهی غالب در این حوزه
تنظیمشده: قانون یا مقررات تعیین میکند کجا و چطور نگهداری شود. استقرار متناسب: درونسازمانی ایزوله یا آفلاین.
مسئله در این حوزه چه شکلی است
- حجم بالای اسناد تکراری — پروندهی تسهیلات، اعلام خسارت، مکاتبات شعب — که هرکدام باید توسط انسان خوانده و دستهبندی شود.
- دادهی مشتری تقریباً در همهی این فرآیندها حاضر است: کد ملی، شماره حساب، شبا، و در بیمه، دادهی سلامت.
- هر تصمیمی که روی پروندهی مشتری اثر بگذارد باید قابل توضیح باشد. «مدل اینطور گفت» پاسخ قابل قبولی نیست.
- واحد انطباق معمولاً دیر وارد پروژه میشود و آنوقت باید چیزی را که ساخته شده از اول توجیه کرد.
سه کار قابل خودکارسازی
۰۱
دستهبندی و مسیردهی مکاتبات ورودی
نامهها و درخواستهای ورودی شعب به واحد درست مسیردهی میشوند. کمریسکترین نقطهی شروع است، چون خطایش همان روز کشف و اصلاح میشود و به تصمیم مالی وصل نیست.
۰۲
استخراج داده از اسناد پرونده
مبلغ، تاریخ، شماره قرارداد و مشخصات از اسناد اسکنشده استخراج و در سامانه وارد میشود. خروجی کاملاً قابل راستیآزمایی است: رقم کنترلی کد ملی باید درست باشد، شبا باید mod-97 را رد کند، و جمع اقلام باید با جمع کل بخواند.
۰۳
پیشنویس پاسخ به استعلام و شکایت
سامانه پیشنویس میسازد و کارشناس تأیید یا اصلاح میکند. انسان در حلقه اینجا اختیاری نیست — پاسخ رسمی به مشتری، سند حقوقی است.
دادهای که هرگز نباید بیرون برود
- کد ملی، شماره حساب، شبا و شماره کارت مشتری
- مانده و گردش حساب
- دادهی سلامت در پروندههای بیمهی درمان
- اطلاعات پروندههای حقوقی و اعتباری در جریان
- سوابق تراکنش قابل انتساب به شخص
معماری استقرار متناسب
درونسازمانی ایزوله. در این حوزه، سطح داده تقریباً همیشه تنظیمشده است و انتخاب معماری از الزام قانونی شروع میشود، نه از قابلیت ابزار. اگر بخشی از داده واقعاً عمومی است — مثل محتوای اطلاعرسانی — میشود آن را در جریان جداگانهای با معماری سبکتر برد.
ریسکهای OWASP LLM مرتبط
LLM02
افشای اطلاعات حساس
مدلی که به پروندهی چند مشتری دسترسی دارد، ممکن است در پاسخ به یک نفر، دادهی دیگری را بازگو کند. تفکیک دسترسی باید در مرحلهی بازیابی اعمال شود، نه بعد از تولید پاسخ.
LLM01
تزریق دستور
اسناد ارسالی مشتری ورودی نامعتمدند. سندی که کارشناس بارگذاری میکند میتواند حاوی دستور پنهان باشد.
LLM09
اطلاعات نادرست
پاسخ ساختگی دربارهی شرایط یک محصول بانکی یا پوشش بیمهای، تعهد حقوقی ایجاد میکند.
نمونهی معیار پذیرش
روی ۲۰۰ سند واقعی خارج از دادهی توسعه، دقت استخراج فیلدهای کلیدی به نرخ توافقشده برسد؛ صفر مورد دسترسی به پروندهای خارج از سطح مجاز کاربر در گزارش تست دسترسی؛ و هر خروجی که به مشتری میرود، رد تأیید انسانی داشته باشد.
عدد دقیق در گفتوگو با شما و بر اساس وضعیت فعلی کارتان تعیین میشود. عددی که بدون شناخت کار شما نوشته شود، تبلیغ است نه معیار.
محدودیتها
- کیفیت تشخیص نوری روی اسناد اسکنشدهی قدیمی و مهرخورده بهطور محسوسی پایینتر است و باید پیش از هر برآوردی روی نمونهی واقعی خودتان سنجیده شود.
- تصمیمهای اعتباری و تشخیص تخلف با اثر مستقیم، برای شروع مناسب نیستند. الزام مستندسازیشان چند برابر است و خطایشان به مشتری آسیب میزند.
- من مشاور حقوقی نیستم. نگاشت کنترلها به الزامات نهاد ناظر باید با واحد انطباق خودتان نهایی شود.
پرسش و پاسخ
آیا میتوانیم از سرویسهای ابری عمومی استفاده کنیم؟
برای دادهی مشتری، نه. برای محتوای کاملاً عمومی مثل متن اطلاعرسانی، بله — بهشرط اینکه جریان کاریاش از جریان دادهی مشتری جدا باشد و این جدایی فنی اعمال شود، نه فقط رویهای.
از کجا شروع کنیم که کمترین ریسک را داشته باشد؟
از دستهبندی مکاتبات ورودی. خطایش همان روز کشف میشود، به تصمیم مالی وصل نیست، و دادهای که پردازش میکند معمولاً از پروندهی اعتباری کمحساستر است.
حسابرس چه چیزی از ما میخواهد؟
در عمل هفت چیز: سیاستنامهی مکتوب، طبقهبندی داده، ثبت تصمیم معماری، مجموعهی ارزیابی با عددش، کارت سیستم، لاگ تفکیکپذیر، و رویهی انسان در حلقه با ثبت هویت تأییدکننده.
مدل را روی دادهی خودمان آموزش میدهید؟
نه. کار من پیادهسازی امن مدلهای موجود در فرآیند شماست. آموزش مدل پایه نه لازم است و نه در این سطح از حساسیت داده توصیه میشود.
پیادهسازی بانک و بیمه از کجا شروع میشود؟
همینجا پاسخ دهید و پتانسیل اتوماسیون کسبوکارتان را بسنجید.
یک جلسهی نیمساعته کافی است تا بفهمیم کدام از این سه کار برای شما اولویت دارد و اولین گام مشخصتان چیست.
اگر این خدمات مناسب شما نباشد، صریحاً به شما میگویم.