آزمایشگاه پردازش زبان طبیعی دانشکده علوم ریاضی دانشگاه فردوسی مشهد، با همکاری شرکت ویرا اندیشه جویان (واج)، از دانشجویان و فارغالتحصیلان مستعد، علاقهمند و باانگیزه برای همکاری در توسعه پروژههای واقعی هوش مصنوعی دعوت میکند.
🔹 حوزههای فعالیت و یادگیری:
▫️ عاملهای هوش مصنوعی (AI Agents & Agentic Systems)
▫️ مدلهای زبانی بزرگ (LLMs)
▫️ مهندسی پرامپت و مدیریت زمینه (Prompt & Context Engineering)
▫️ خودکارسازی فرایندها و گردشکارهای هوشمند
▫️ اتصال مدلهای زبانی به ابزارها و APIها
▫️ بازیابی اطلاعات و تولید تقویتشده (RAG)
▫️ سیستمهای چندعاملی (Multi-Agent Systems)
🔹 مهارتهای موردنیاز:
▫️ آشنایی مناسب با Python
▫️ آشنایی اولیه با مفاهیم هوش مصنوعی و مدلهای زبانی
▫️ آشنایی با REST API، Git و پایگاه داده
▫️ توانایی مطالعه مستندات فنی انگلیسی
▫️ علاقهمندی به حل مسئله، تحقیق و یادگیری مستمر
آشنایی با OpenAI API، LangChain، LangGraph، FastAPI و داشتن پروژههای شخصی مرتبط، مزیت محسوب میشود.
✅ لازم نیست به همه فناوریهای ذکرشده مسلط باشید! پایه برنامهنویسی مناسب، انگیزه یادگیری و علاقه به ساخت سامانههای هوشمند برای ما اهمیت زیادی دارد.
👤 شرایط پذیرش: در این مرحله از جذب، پذیرش کارآموز به متقاضیان آقا محدود است. ارزیابی متقاضیان بر اساس سوابق تحصیلی، توانایی برنامهنویسی، تجربه عملی، انگیزه و ظرفیت یادگیری انجام خواهد شد.
🚀 فرصت همکاری پس از دوره کارآموزی:
در صورت گذراندن موفقیتآمیز دوره کارآموزی و احراز شرایط موردنیاز، امکان جذب و ادامه همکاری در شرکت ویرا اندیشه جویان (واج) فراهم خواهد بود.
📝 فرم ثبتنام و ارزیابی:
لطفاً برای ثبت اطلاعات تحصیلی، مهارتها و سوابق خود، فرم زیر را تکمیل کنید:
ISO published something I think a lot of security teams are going to need soon: ISO/IEC 27090, guidance on securing AI systems themselves.
Not "using AI for security." Securing the AI.
I went through everything ISO has made public about it, added a few solid practitioner reviews, and turned my notes into a guide. Mostly because I wanted one place that explains it without drowning in jargon.
A few things that stood out to me:
• It names nine AI-specific threats, from data poisoning and prompt injection to stealing a model through API calls that look completely normal.
• It's guidance, not a certificate. There's no such thing as "27090 certified." It's meant to sit inside your 27001 or 42001 program.
• The one I keep coming back to: data collected in production often ends up in retraining. So a poisoned input today can quietly become a weakness in next quarter's model.
The guide walks through the three pillars of the standard, each threat with real incidents behind it, a worked example, questions to ask your AI vendors, and an evidence checklist for audits.
It's free and attached to this post. There's a Persian version too.
If you're already threat-modelling your AI systems, I'd genuinely like to hear what's working for you. And if you spot something I got wrong, please tell me.
A strong SOC is not built by buying more tools. It is built by choosing the right capabilities and making them work together.
Modern Security Operations Centers need visibility across endpoints, identities, networks, vulnerabilities, and threat intelligence while giving analysts the automation and context required to respond quickly. 🛡
This SOC tooling map provides a useful comparison between commercial platforms and open-source alternatives across key capabilities:
But the technology itself is only part of the equation.
The real objective is building an operational cycle where teams can Detect → Investigate → Respond → Improve continuously. 🔄
Open-source does not automatically mean “less capable,” and commercial does not automatically mean “better.” Architecture, integration, telemetry quality, detection engineering, automation, analyst expertise, and operational maturity ultimately determine how effective a SOC becomes.
💡 If you were building a SOC from scratch today, which THREE tools or capabilities would be non-negotiable in your stack?
Share your picks in the comments 👇 I’m curious to see how different SOC teams would design their stack.