همکاران
صنعت ساختمان و نظام برنامه‌ریزی و مدیریت شهری در حال تجربه یکی از مهم‌ترین دوره‌های تحول فناورانه خود است. در دو دهه گذشته، ابزارهایی مانند طراحی رایانه‌ای، سیستم‌های اطلاعات جغرافیایی و مدل‌سازی اطلاعات ساختمان، شیوه تولید، ذخیره و تبادل اطلاعات را در پروژه‌های ساختمانی تغییر داده‌اند. در سال‌های اخیر نیز فناوری‌هایی مانند اینترنت اشیا، دوقلوهای دیجیتال، هوش مصنوعی و مدل‌های زبانی بزرگ، افق جدیدی برای تحلیل و تصمیم‌گیری در محیط ساخته‌شده ایجاد کرده‌اند.
با وجود این تحولات، یک جزء اساسی از فرآیند ساخت‌وساز همچنان عمدتاً در قالبی طراحی شده برای خوانش و تفسیر انسانی باقی مانده است: مقررات.
مقررات ساختمانی و شهرسازی معمولاً در قالب متون حقوقی و فنی، جداول، نقشه‌های پهنه‌بندی، تبصره‌ها، پیوست‌ها و بخشنامه‌ها منتشر می‌شوند. این ساختار برای ارتباط میان انسان‌ها و نهادهای تصمیم‌گیرنده مناسب است، اما الزاماً برای پردازش ماشینی مناسب نیست.
این تفاوت در ظاهر ساده، پیامد مهمی دارد. ممکن است یک شهرداری دارای سامانه الکترونیکی صدور پروانه، نقشه‌های دیجیتال، بانک اطلاعات مکانی و حتی امکان دریافت فایل BIM باشد، اما همچنان برای پاسخ به پرسش‌هایی مانند «چه مقدار سطح اشغال مجاز است؟»، «حداکثر ارتفاع این ساختمان چقدر است؟» یا «آیا این طرح با ضوابط کاربری زمین منطبق است؟» نیازمند تفسیر انسانی مقررات باشد.
از این منظر باید میان دو مفهوم تمایز قائل شد:
دیجیتال‌شدن اطلاعات و قابل پردازش‌شدن اطلاعات.
یک سند PDF ممکن است کاملاً دیجیتال باشد، اما اگر ساختار معنایی و منطق درونی آن برای ماشین مشخص نباشد، نمی‌توان انتظار داشت که سیستم به شکل قابل اعتماد از آن برای تصمیم‌گیری استفاده کند.
این مسئله در ادبیات علمی جدید با مفهوم Automated Compliance Checking یا کنترل خودکار انطباق با مقررات شناخته می‌شود. پژوهش‌های جدید نشان می‌دهند که نسل اولیه این سیستم‌ها عمدتاً بر قواعدی متکی بودند که متخصصان به‌صورت دستی از مقررات استخراج و در نرم‌افزار تعریف می‌کردند؛ اما این رویکرد به دلیل هزینه زیاد مدل‌سازی قواعد و دشواری به‌روزرسانی آنها، مقیاس‌پذیری محدودی داشت. پژوهش‌های ۲۰۲۶ اکنون به سمت استخراج خودکار قواعد، هستی‌شناسی، پردازش زبان طبیعی و LLM حرکت کرده‌اند. بر همین اساس، پرسش اصلی این مقاله چنین صورت‌بندی می‌شود:
چگونه می‌توان ضوابط ساخت‌وساز و شهرسازی را از قالب متون و اسناد قابل خوانش انسانی به قواعد ساختاریافته و ماشین‌خوان تبدیل کرد و آنها را به داده‌های مکانی و مدل‌های دیجیتال ساختمان متصل ساخت؟
نظام کنترل ساخت‌وساز اساساً یک نظام «تصمیم‌گیری مبتنی بر مقررات» است. در ساده‌ترین بیان، هر پروژه ساختمانی مجموعه‌ای از ویژگی‌ها دارد و باید بررسی شود که آیا این ویژگی‌ها با مجموعه‌ای از الزامات قانونی و فنی منطبق هستند یا خیر.
اگر پروژه را با مجموعه‌ای از متغیرها مانند (X) و مقررات حاکم را با مجموعه‌ای از قواعد (R) نمایش دهیم، مسئله کنترل انطباق را می‌توان به صورت ساده چنین بیان کرد:
[Compliance = f(X,R)]
در سیستم سنتی، بخش عمده تابع (f) توسط انسان اجرا می‌شود. یعنی کارشناس ابتدا مقررات مربوطه را شناسایی و تفسیر می‌کند، سپس اطلاعات پروژه را استخراج کرده و در نهایت درباره انطباق آن تصمیم می‌گیرد.
اما در نظام مقررات ماشین‌خوان، هدف آن است که بخش قابل‌توجهی از این تابع به صورت محاسباتی قابل اجرا شود.
این تحول در ظاهر یک مسئله فناوری اطلاعات است، اما در واقع ماهیتی چندرشته‌ای دارد؛ زیرا سه حوزه باید همزمان با یکدیگر سازگار شوند:
منطق حقوقی و مقرراتی
مدل اطلاعاتی پروژه
مدل داده‌ای و محاسباتی
اگر هر یک از این سه لایه ناسازگار باشد، اتوماسیون کنترل مقررات با شکست مواجه خواهد شد. برای مثال، اگر مدل BIM اطلاعات سطح اشغال را نداشته باشد، حتی بهترین موتور قواعد نیز قادر به بررسی آن نخواهد بود. اگر مدل BIM کامل باشد اما ضابطه سطح اشغال به شکل مبهم و بدون ساختار منطقی تعریف شده باشد، سیستم نمی‌تواند آن را اجرا کند. و اگر هر دو موجود باشند اما مشخص نباشد کدام نسخه از ضابطه در تاریخ مشخص معتبر بوده است، خروجی سیستم ممکن است از نظر حقوقی قابل اتکا نباشد.
بنابراین مسئله اصلی را نمی‌توان صرفاً «هوشمندسازی کنترل نقشه» نامید؛ بلکه مسئله بنیادی‌تر، ایجاد یک زنجیره پیوسته از مقررات تا داده و از داده تا تصمیم است.
ماشین‌خوان بودن مقررات مفهومی بسیار فراتر از OCR یا تبدیل PDF به متن است. فرض کنیم در یک ضابطه آمده باشد: حداکثر سطح اشغال ساختمان در طبقه همکف ۶۰ درصد مساحت قطعه است. برای انسان، این عبارت تقریباً یک دستور روشن است. اما برای ماشین باید مشخص شود:
· موضوع قاعده چیست؟
· «سطح اشغال» چگونه تعریف شده است؟
· «طبقه همکف» دقیقاً چه فضایی را شامل می‌شود؟
· متغیر مرجع برای محاسبه چیست؟
· مقدار مجاز چقدر است؟
· دامنه جغرافیایی قاعده چیست؟
· آیا استثنایی وجود دارد؟
· تاریخ اعتبار قاعده چیست؟
· اگر ضابطه دیگری با آن تعارض داشته باشد، کدام اولویت دارد؟
بنابراین یک قاعده ماشین‌خوان باید حداقل دارای اجزای زیر باشد:
شرایط اعمال → متغیرهای موردنیاز → الزام → مقدار یا منطق ارزیابی → استثنا → منبع و نسخه
برای نمونه:
اگر پهنه = A
و
نوع ساختمان = مسکونی
آنگاه:
حداکثر سطح اشغال طبقه همکف = ۰٫۶ × مساحت قطعه
و در صورت وجود استثنا، آن استثنا نیز باید به شکل صریح در مدل داده ثبت شود.
پژوهش‌های اخیر دقیقاً به همین سمت حرکت کرده‌اند. پژوهش Zentgraf و همکاران در سال ۲۰۲۶ چارچوبی را معرفی کرده که از اطلاعات معنایی و هستی‌شناسی برای استخراج الزامات و تبدیل آنها به قواعد قابل اعتبارسنجی با SHACL استفاده می‌کند. هدف این رویکرد، کاهش تلاش دستی در مدل‌سازی قواعد و افزایش قابلیت نگهداری سیستم در مواجهه با تغییر مقررات است.
نسل اول سیستم‌های کنترل خودکار مقررات عمدتاً بر Rule-Based Systems استوار بود.
در این روش، متخصص مقررات را می‌خواند و قواعد آن را به زبان قابل اجرای نرم‌افزار تبدیل می‌کرد. برای مثال:
IF building_height > permitted_height
THEN non-compliant
این روش برای مقررات ساده بسیار مناسب است؛ اما با افزایش پیچیدگی مقررات، مشکلات آن آشکار می‌شود. مقررات واقعی معمولاً شامل تبصره‌ها، ارجاع‌ها، استثناها، شرایط وابسته به یکدیگر و روابط میان چند سند هستند. در نتیجه، تعداد قواعد افزایش پیدا می‌کند و به‌روزرسانی سیستم دشوار می‌شود.
مطالعه مروری Lee و همکاران در سال ۲۰۲۶ نشان می‌دهد که حوزه Automated Compliance Checking در حال عبور از سیستم‌های صرفاً Rule-Based به سمت ترکیب AI، LLM و Ontology است. این تغییر ناشی از نیاز به کاهش هزینه استخراج و مدل‌سازی دستی قواعد و همچنین امکان کار با مقررات پیچیده و زبان طبیعی است.
در پژوهشی دیگر، Iversen و Huang در سال ۲۰۲۶ یک چارچوب مبتنی بر LLM برای کنترل خودکار انطباق ارائه کردند که در آن مدل زبانی برای تفسیر مقررات، استخراج داده از BIM، اجرای کنترل‌ها و تولید گزارش انطباق استفاده شده است. نویسندگان در آزمایش‌های خود دقت بالایی در برخی مراحل استخراج و اجرای قواعد گزارش کرده‌اند؛ با این حال، چنین نتایجی باید در محیط‌های حقوقی و مقرراتی واقعی با احتیاط و اعتبارسنجی مستقل تفسیر شود.
این نکته بسیار مهم است: هوش مصنوعی الزاماً جایگزین موتور قواعد نمی‌شود.
مدل مناسب آینده احتمالاً معماری ترکیبی خواهد داشت:
LLM برای فهم و استخراج → Ontology برای معنا → Rule Engine برای اجرای قطعی → BIM/GIS برای داده → Human Expert برای موارد استثنایی و تصمیم نهایی
یکی از پیش‌شرط‌های مهم کنترل خودکار مقررات، وجود داده ساختاریافته درباره ساختمان است.
در اینجا BIM اهمیت پیدا می‌کند. BIM را نباید صرفاً یک مدل سه‌بعدی دانست. در تعریف حرفه‌ای، BIM یک محیط مدیریت اطلاعات است که می‌تواند اطلاعات هندسی و غیرهندسی اجزای ساختمان را در یک ساختار قابل استفاده در مراحل مختلف چرخه عمر پروژه سازمان‌دهی کند.
اما برای کنترل مقررات، صرف داشتن مدل BIM کافی نیست.
مدل باید اطلاعات موردنیاز برای ارزیابی مقررات را داشته باشد.
برای مثال، اگر قرار است پارکینگ کنترل شود، سیستم باید بتواند اطلاعات مرتبط با تعداد، ابعاد، موقعیت و نوع پارکینگ را از مدل استخراج کند.
اگر قرار است سطح اشغال بررسی شود، مرز قطعه، محدوده ساخت و قواعد مربوط به محاسبه سطح اشغال باید قابل شناسایی باشند.
از این منظر، یک مفهوم مهم مطرح می‌شود:
Information Requirements
یعنی قبل از کنترل مقررات باید مشخص شود که برای اجرای هر قاعده، چه اطلاعاتی از مدل لازم است.
پژوهش‌های جدید دقیقاً بر همین موضوع تمرکز کرده‌اند. چارچوب Zentgraf و همکاران با استفاده از الزامات اطلاعاتی و استانداردهای معنایی تلاش می‌کند ارتباط مستقیم‌تری میان مقررات و داده‌های مدل ساختمان ایجاد کند.
۶. چرا GIS برای شهرسازی ماشین‌خوان ضروری است؟
BIM عمدتاً درباره ساختمان صحبت می‌کند، اما بسیاری از ضوابط شهرسازی به مکان وابسته‌اند.
برای مثال: کاربری زمین/ پهنه/ عرض گذر/ فاصله از معبر/ محدودیت‌های ارتفاعی/ فاصله از عناصر زیرساختی/ محدوده‌های حفاظتی/ حریم‌ها/ تراکم مجاز، همگی ویژگی‌هایی هستند که بدون اطلاعات مکانی نمی‌توان آنها را به شکل کامل ارزیابی کرد.
در نتیجه، یک نظام کنترل مقررات شهری نیازمند اتصال BIM و GIS است. می‌توان این رابطه را به صورت زیر خلاصه کرد:
GIS → می‌گوید این پروژه کجاست و چه مقررات مکانی بر آن حاکم است.
BIM → می‌گوید این پروژه چگونه طراحی شده است.
Rule Engine → بررسی می‌کند آیا طراحی با مقررات حاکم منطبق است یا خیر.
این سه لایه در کنار هم می‌توانند هسته یک نظام Digital Building Permit یا حتی در مقیاس بزرگ‌تر یک Urban Digital Twin مبتنی بر مقررات را تشکیل دهند.
یکی از نمونه‌های مهم در این زمینه، تجربه سنگاپور و پروژه CORENET X است.
CORENET X با هدف بازطراحی فرآیند تأیید مقرراتی پروژه‌های ساختمانی ایجاد شده و بر استفاده از BIM، هماهنگی میان دستگاه‌های مختلف و کاهش تعاملات پراکنده در فرآیند صدور مجوز تمرکز دارد.
بر اساس اطلاعات رسمی دولت سنگاپور، پروژه‌ها در این چارچوب می‌توانند مدل سه‌بعدی هماهنگ‌شده خود را برای بررسی مقرراتی ارائه کنند و فرآیند جدید به سمت هماهنگی پیش از ارسال رسمی و بررسی یکپارچه حرکت کرده است.
در حال حاضر، CORENET X صرفاً یک مفهوم آزمایشگاهی نیست. طبق اطلاعات رسمی URA، برای پروژه‌های دارای زیربنای ناخالص ۵۰۰۰ مترمربع و بیشتر، قالب IFC+SG در فرآیندهای مشخص ارائه الزامی شده و سامانه دارای ابزارهای کنترل کیفیت مدل است.
این تجربه از منظر ایران اهمیت زیادی دارد؛ زیرا نشان می‌دهد تحول دیجیتال در صدور مجوز صرفاً با افزودن یک «سامانه آنلاین» اتفاق نمی‌افتد. لازم است فرآیند، داده، استاندارد و مقررات همزمان بازطراحی شوند.
یکی از جدیدترین جهت‌گیری‌های پژوهشی، تغییر سؤال از «چگونه مقررات را خودکار کنیم؟» به «آیا مقررات موجود اساساً برای خودکارسازی آماده هستند؟» است.
پژوهش Beach، Kabzhan و Shakhnovich در سال ۲۰۲۶ دقیقاً این مسئله را بررسی کرده و مفهوم Regulatory Readiness را مطرح می‌کند. در این پژوهش، قابلیت رسمی‌سازی بندهای مقرراتی در اسناد مرتبط با دسترس‌پذیری و ایمنی حریق در بریتانیا و قزاقستان بررسی شده است.
این موضوع برای ایران اهمیت دوچندان دارد.
ممکن است دو ضابطه از نظر انسانی کاملاً روشن به نظر برسند، اما یکی قابلیت تبدیل مستقیم به Rule داشته باشد و دیگری به دلیل ابهام، ارجاع به بند دیگر یا وابستگی به قضاوت کارشناسی، نیازمند مداخله انسانی باشد.
از این منظر، همه ضوابط را نباید به یک اندازه برای اتوماسیون مناسب دانست. می‌توان سه سطح برای آنها تعریف کرد:
سطح اول: ضوابط کاملاً قابل اتوماسیون: مانند برخی محاسبات عددی مشخص:
حداقل مساحت
حداکثر ارتفاع
تعداد پارکینگ
درصد سطح اشغال
سطح دوم: ضوابط نیمه‌خودکار
قواعدی که بخشی از آنها قابل محاسبه است، اما نیازمند تفسیر یا بررسی استثنا هستند.
سطح سوم: ضوابط نیازمند قضاوت تخصصی
مواردی که ماهیت حقوقی، کیفی، زمینه‌ای یا تفسیری دارند.
مطالعه موردی جدید شهر وین در سال ۲۰۲۶ نیز از سه سطح automatic، semi-automatic و graphical assistance برای کنترل مقررات سخن می‌گوید. این رویکرد نشان می‌دهد که هدف واقع‌بینانه، «اتوماسیون صددرصدی» نیست؛ بلکه انتخاب سطح مناسب اتوماسیون برای هر قاعده است.
نظام شهرسازی ایران از نظر ساختار حقوقی و نهادی با سیستم‌هایی که صرفاً یک Building Code واحد دارند متفاوت است. ضوابط توسعه و عمران در ایران در سطوح و اسناد مختلف شکل می‌گیرند و طرح‌های جامع، تفصیلی، ضوابط و مقررات شهرسازی و معماری و مصوبات مرتبط، در تصمیم‌گیری‌های شهری نقش دارند.
برای نمونه، «آیین‌نامه نحوه بررسی و تصویب طرح‌های توسعه و عمران محلی، ناحیه‌ای، منطقه‌ای و ملی و مقررات شهرسازی و معماری کشور» ساختار و جایگاه انواع طرح‌ها از جمله طرح جامع و طرح تفصیلی و مراجع بررسی و تصویب آنها را مشخص می‌کند.
همچنین در همین ساختار، تغییرات طرح‌های تفصیلی و نسبت آنها با طرح‌های جامع، فرآیندهای کارشناسی و تصویب مشخصی دارند. این مسئله نشان می‌دهد که ضابطه شهرسازی یک موجودیت ثابت و مستقل نیست؛ بلکه با مرجع تصویب، تاریخ، محدوده جغرافیایی و روابط میان اسناد پیوند دارد.
این ویژگی برای طراحی یک سیستم ماشین‌خوان بسیار مهم است. سیستم باید بتواند تشخیص دهد:
· کدام ضابطه؟
· برای کدام محدوده؟
· در چه تاریخی؟
· با چه سطحی از اعتبار؟
· با چه استثناهایی؟
و:
در صورت تعارض دو ضابطه، کدام‌یک اولویت دارد؟
بنابراین، مسئله ایران صرفاً «تبدیل PDF به Rule» نیست؛ بلکه نیازمند ایجاد یک مدل دانش مقررات شهرسازی ایران است.
بر اساس ادبیات بررسی‌شده، می‌توان یک معماری مفهومی شش‌لایه برای توسعه نظام ضوابط ماشین‌خوان در ایران پیشنهاد کرد.
لایه اول: مخزن مقررات، در این لایه تمام اسناد معتبر جمع‌آوری می‌شوند:
قوانین/ آیین‌نامه‌ها/ ضوابط/ طرح‌های جامع/ طرح‌های تفصیلی/ مصوبات/ بخشنامه‌ها/ دستورالعمل‌ها
هر سند باید دارای شناسه، منبع، تاریخ تصویب، تاریخ اعتبار و محدوده جغرافیایی باشد.
لایه دوم: پایگاه دانش مقررات، در این مرحله، متن خام به ساختار معنایی تبدیل می‌شود.
مفاهیمی مانند: قطعه، کاربری، پهنه، تراکم، سطح اشغال، ارتفاع، طبقه، معبر، پارکینگ و عقب‌نشینی باید در یک واژگان کنترل‌شده و مشترک تعریف شوند.
این لایه را می‌توان Regulatory Knowledge Base نامید.
لایه سوم: موتور قواعد، در این لایه قواعد قابل اجرا ایجاد می‌شوند.
برای نمونه:
[GFA_{max}=A_{plot}\times FAR_{allowed}]
یا:
[Footprint_{max}=A_{plot}\times Coverage_{allowed}]
سیستم می‌تواند مقدار طراحی‌شده را با مقدار مجاز مقایسه کند.
لایه چهارم: GIS، اطلاعات مکانی پروژه به پایگاه مقررات متصل می‌شود.
در این مرحله سیستم تشخیص می‌دهد که:
این ملک در کدام پهنه قرار دارد؟
چه طرح تفصیلی بر آن حاکم است؟
چه محدودیت‌های مکانی دارد؟
لایه پنجم: BIM، مدل ساختمان به سیستم متصل می‌شود.
اطلاعات هندسی و غیرهندسی ساختمان از BIM استخراج شده و به Rule Engine ارسال می‌شود.
لایه ششم: AI و کارشناس انسانی، هوش مصنوعی در این لایه می‌تواند برای:
استخراج اولیه قواعد/ تشخیص تعارض مقررات/ تحلیل تبصره‌ها/ جست‌وجوی معنایی/ پیشنهاد تفسیر/ تولید گزارش استفاده شود.
اما خروجی‌های حساس باید به کارشناس ارجاع شوند.
این همان مدل Human-in-the-Loop است که در پژوهش‌های جدید نیز به‌عنوان یکی از عناصر افزایش اعتماد و قابلیت ردیابی سیستم مطرح شده است.
در صورت اجرای صحیح، ضوابط ماشین‌خوان می‌توانند چند تحول اساسی ایجاد کنند.
کاهش خطاهای ناشی از کنترل دستی: وقتی یک قاعده مشخص به صورت یکسان برای همه پروژه‌ها اجرا شود، اختلاف ناشی از محاسبه دستی کاهش پیدا می‌کند.
افزایش سرعت بررسی: بخشی از کنترل‌های تکراری می‌تواند پیش از بررسی کارشناسی انجام شود.
افزایش شفافیت: متقاضی می‌تواند بفهمد چرا یک طرح رد یا پذیرفته شده است.
کاهش رفت‌وبرگشت پرونده: اگر سیستم در مرحله طراحی اولیه، عدم انطباق را شناسایی کند، اصلاح پیش از ارسال رسمی انجام می‌شود.
افزایش قابلیت ردیابی: هر تصمیم می‌تواند به یک قاعده، نسخه و داده مشخص متصل باشد.
امکان تحلیل سیاست‌های شهری: اگر مقررات و داده‌های پروژه‌ها ساختاریافته شوند، مدیران شهری می‌توانند پیامد تغییر یک ضابطه را نیز شبیه‌سازی کنند.
نخستین خطر، اتوماسیون یک ضابطه نادرست است. اگر Rule اشتباه باشد، سرعت بالاتر فقط باعث می‌شود خطا سریع‌تر تکثیر شود.
دومین خطر، تفسیر نادرست زبان طبیعی است. مدل‌های زبانی ممکن است در فهم تبصره‌ها، ارجاع‌های حقوقی یا روابط پیچیده دچار خطا شوند.
سومین مسئله، مسئولیت حقوقی است. اگر سامانه اعلام کند پروژه منطبق است اما بعداً مشخص شود که نتیجه اشتباه بوده، مسئولیت با چه شخص یا نهادی خواهد بود؟
چهارمین مسئله، نسخه‌بندی مقررات است. یک تصمیم ممکن است در سال ۱۴۰۲ بر اساس یک ضابطه صحیح باشد و همان تصمیم در سال ۱۴۰۵ بر اساس مقررات جدید دیگر صحیح نباشد.
بنابراین سیستم باید بتواند وضعیت مقررات را در زمان مشخص بازسازی کند.
پنجمین مسئله، استانداردسازی داده‌ها است. اگر شهرداری‌ها، مشاوران، سازمان‌های دولتی و نرم‌افزارهای مختلف از تعاریف و ساختارهای متفاوت استفاده کنند، اتصال آنها دشوار خواهد بود.
بررسی ادبیات جدید نشان می‌دهد که حوزه کنترل خودکار انطباق در حال ورود به مرحله‌ای متفاوت است. در نسل نخست، سؤال این بود: چگونه یک Rule را به نرم‌افزار تبدیل کنیم؟ در نسل جدید، سؤال گسترده‌تر شده است: چگونه کل زنجیره مقررات، داده، مدل، منطق و تصمیم را دیجیتال کنیم؟
این تغییر نگرش اهمیت زیادی دارد.
پژوهش ۲۰۲۶ درباره استخراج خودکار مقررات از استانداردها نشان می‌دهد که حتی در پروژه‌های پیشرفته نیز یکی از گلوگاه‌های اصلی، تبدیل مقررات غیرماشین‌خوان به قواعد ساختاریافته است.
از سوی دیگر، پژوهش‌های جدید مبتنی بر LLM نشان می‌دهند که هوش مصنوعی می‌تواند بخشی از این گلوگاه را کاهش دهد. اما این فناوری هنوز جایگزین نیاز به مدل داده، کنترل کیفیت، اعتبارسنجی و نظارت انسانی نیست.
در واقع، آینده محتمل این حوزه را نباید «AI جایگزین کارشناس می‌شود» دانست. مدل محتمل‌تر این است:
AI → مقررات را می‌خواند و ساختار می‌دهد
Ontology → معنای مفاهیم را تثبیت می‌کند
Rule Engine → قواعد قطعی را اجرا می‌کند
BIM/GIS → داده واقعی پروژه و مکان را فراهم می‌کنند
کارشناس → موارد پیچیده و استثنایی را بررسی می‌کند
نهاد قانونی → مسئولیت و اعتبار تصمیم را تعیین می‌کند
این معماری از نظر حرفه‌ای و حقوقی واقع‌بینانه‌تر است.
تحول دیجیتال در ساخت‌وساز و شهرسازی زمانی به مرحله بلوغ خواهد رسید که علاوه بر مدل‌سازی ساختمان و دیجیتالی‌کردن فرآیندهای اداری، خودِ منطق مقررات نیز قابلیت پردازش ماشینی پیدا کند.
مفهوم «ضابطه ماشین‌خوان» از این منظر یک فناوری منفرد نیست؛ بلکه نقطه اتصال چند حوزه است:
حقوق و مقررات + شهرسازی + BIM + GIS + هوش مصنوعی + مدیریت اطلاعات
پژوهش‌های ۲۰۲۵ و ۲۰۲۶ نشان می‌دهند که این حوزه به‌سرعت در حال حرکت از سیستم‌های مبتنی بر قواعد دستی به سمت روش‌های ترکیبی مبتنی بر Ontology، NLP و LLM است. در عین حال، ادبیات جدید تأکید می‌کند که پیش‌نیاز موفقیت این تحول، آماده‌بودن خود مقررات برای رسمی‌سازی، قابلیت ردیابی قواعد، مدیریت نسخه‌ها و حفظ نقش انسان در تصمیم‌های پیچیده است.
برای ایران، این تحول اهمیت ویژه‌ای دارد؛ زیرا نظام توسعه و عمران شهری متکی بر مجموعه‌ای از طرح‌ها، ضوابط، مقررات و مراجع تصمیم‌گیر است و همین تعدد منابع، پیچیدگی تبدیل مقررات به قواعد ماشینی را افزایش می‌دهد.
بنابراین پیشنهاد این مقاله، حرکت مستقیم به سمت «صدور کاملاً خودکار پروانه» نیست. نقطه شروع باید ایجاد یک زیرساخت ملی/شهری دانش مقررات باشد که در آن هر ضابطه دارای شناسه، منبع، محدوده مکانی، تاریخ اعتبار، روابط با سایر ضوابط و منطق قابل پردازش باشد.
در گام بعد می‌توان این پایگاه را به GIS، BIM و موتور کنترل مقررات متصل کرد و سپس از هوش مصنوعی برای استخراج و تحلیل مقررات استفاده نمود.
در چنین الگویی، آینده شهرسازی دیجیتال نه در حذف کارشناس، بلکه در تغییر نقش کارشناس از جست‌وجوگر و محاسبه‌گر مقررات به ناظر، تحلیلگر و تصمیم‌گیر حرفه‌ای شکل خواهد گرفت.
در نهایت، پرسش آینده نظام صدور مجوز ساخت‌وساز دیگر صرفاً این نخواهد بود که:
«آیا این ساختمان با ضوابط مطابقت دارد؟»
بلکه باید بتوان پرسید:
«سیستم بر اساس کدام ضابطه، در چه نسخه‌ای، با استفاده از کدام داده و با چه منطق قابل ردیابی، به این نتیجه رسیده است؟»
پاسخ به این پرسش می‌تواند یکی از شاخص‌های بلوغ واقعی شهرسازی دیجیتال در دهه آینده باشد.
سیداد