ה-AI כבר בתוך הארגון. עכשיו מגיע החלק הקשה באמת: מי מנהל את הסיכון? AI Governance

לפני שנה-שנתיים רוב השיחות שלנו עם ארגונים על AI התחילו בשאלה:

"איך אפשר להשתמש בזה?"

והיום הדרכות אוריינות AI ואבטחת מידע ב-AI הפכו לנושא מרכזי בארגונים.

היום השאלה כבר אחרת.

• עובדים משתמשים ב-ChatGPT, Claude, Gemini וכלים נוספים
• מפתחים נעזרים ב-AI לכתיבת קוד
• מחלקות שיווק מנתחות מידע
• מנהלים מעלים מסמכים לסיכום
• צוותי שירות מטמיעים Chatbots
• מערכות SaaS מקבלות יכולות AI בעדכון גרסה
• ו-AI Agents מתחילים לקבל גישה ל-CRM, למייל, למערכות ארגוניות ולמאגרי מידע

במילים אחרות:

ה-AI כבר נכנס בדלת.

כאן אנחנו באינפוגארד מתחילים לשאול את השאלות שפחות נוח לשאול:

• מי אישר?
• איזה מידע נכנס?
• מי בדק את הספק?
• מהי רמת הסיכון?
• האם העובדים יודעים מה אסור להעלות?
• האם קיימת בקרה על הרשאות?
• האם קיים Human Oversight?
• ומי אחראי אם משהו משתבש?

AI Governance הוא לא ניהול ChatGPT

אחת הטעויות היא לצמצם את הדיון לשאלה:

האם מותר לעובדים להשתמש ב-ChatGPT?

זו שאלה חשובה, אבל היא רק חלק קטן מהתמונה.

AI נמצא כיום בתוך:

• כלי Generative AI
• מערכות SaaS
• Microsoft Copilot וכלי Productivity
• מערכות CRM
• HR
• Marketing
• כלי פיתוח
• Security Tools
• APIs
• Plugins ו-Browser Extensions
• מודלים שהארגון מפתח בעצמו
• AI Agents

ולעתים המשתמש אפילו אינו יודע שהוא משתמש ב-AI.

לכן AI Governance צריך להתייחס לכל סביבת ה-AI הארגונית, ולא רק למוצר אחד.

הרגולציה סוגרת את הפער בין "אפשר" ל"מותר"

הטכנולוגיה מתפתחת מהר יותר מרוב מנגנוני הניהול הארגוניים.

אבל הרגולציה מתחילה לסגור את הפער.

תקן ISO 42001 ורגולציה EU AI Act הם הדוגמות המרכזיות לרגולציה מתקברת בתחום הבינה המלאכותית.

החוק האירופי מבוסס על רמות סיכון ומטיל דרישות שונות בהתאם למערכת, לשימוש ולהשפעה האפשרית שלה.

נכון לאוגוסט 2026, חלק משמעותי ממנגנוני האכיפה כבר פועל, וב-2 באוגוסט 2026 נכנסו לתוקף גם דרישות שקיפות נוספות לגבי מערכות AI ותוכן שנוצר או שונה באמצעות AI.

אבל מבחינת ארגון ישראלי, השאלה החשובה אינה רק:

"האם ה-EU AI Act חל עלינו?"

אלא גם:

"האם יש לנו Governance שמאפשר לנו להסביר כיצד אנחנו מנהלים AI?"

כי גם בלי תחולה ישירה של רגולציה אירופית, לקוחות, דירקטוריונים, חברות ביטוח, ספקים ושותפים עסקיים מתחילים לשאול את אותן שאלות.

דווקא הפרטיות היא המקום שבו הרבה ארגונים מפספסים

אנחנו רואים ארגונים שמתייחסים ל-AI כאל מוצר טכנולוגי.

בפועל, הוא קודם כול צרכן משמעותי של מידע.

המערכת רוצה:

• עוד מסמכים
• עוד הקשר
• עוד מידע על לקוחות
• עוד מידע על עובדים
• עוד אינטגרציות
• ועוד הרשאות

וזה בדיוק המקום שבו סיכוני הפרטיות מתחילים.

כאשר עובד מעתיק למערכת AI תכתובת עם לקוח, מסמך HR, קוד, חוזה, מידע רפואי או מידע עסקי, מבחינתו הוא אולי רק מבקש "סיכום".

מבחינת הארגון, לעומת זאת, מתרחשת פעולת עיבוד מידע.

לכן צריך להבין:

• האם השימוש במידע תואם למטרה שלשמה נאסף?
• האם באמת צריך להעביר את כולו?
• האם אפשר לבצע Data Minimization?
• האם ניתן לבצע Masking או Anonymization?
• האם הספק שומר את הנתונים?
• האם הוא משתמש בהם לאימון?
• איפה המידע נשמר?
• כמה זמן?
• מי רשאי לצפות בו?
• והאם קיימת דרך למחוק אותו?

כאן מתחבר AI Governance ישירות ל-Privacy by Design, ל-GDPR, חוק הגנת הפרטיות ותיקון 13 ול-DPO.

המטרה היא לא לחכות שהמערכת תעלה לפרודקשן ואז לשאול מה היא עושה עם המידע.

צריך לשאול את השאלות האלה לפני החיבור.

AI Governance אינו נוהל של שני עמודים

אפשר לכתוב:

• "מותר ChatGPT Enterprise".
• "אסור חשבון פרטי".
• "לא מעלים מידע רגיש".

אלה כללים חשובים, אבל הם לא AI Governance.

Governance אמיתי מתחיל כאשר הארגון יודע לענות על שאלות כמו:

• איזה מערכות AI קיימות?
• מי ה-Owner?
• מהו ה-Use Case?
• איזה מידע מעובד?
• לאילו מערכות קיימת גישה?
• מי הספק?
• מה רמת הסיכון?
• מי אישר?
• מתי נבדקה המערכת לאחרונה?

לכן אחת הפעולות הראשונות שאנחנו ממליצים לבצע היא לבנות AI Inventory.

מה צריך להיות ב-AI Inventory?

רכיב	מה מתעדים
מערכת / כלי	שם המערכת, המודל, API או Agent
Owner	בעל התהליך או היחידה העסקית
Use Case	מה בדיוק רוצים לבצע
Data	סוגי המידע שהמערכת מקבלת
Integrations	אילו מערכות מחוברות אליה
Vendor	ספק וספקי משנה
Permissions	הרשאות וגישה
Decision Impact	האם AI רק מייעץ או גם משפיע על החלטה
Human Oversight	מי בודק את התוצאה
Risk Level	רמת הסיכון
Approval	מי אישר את השימוש
Review Date	מועד בחינה מחדש

לא חייבים להתחיל ממערכת GRC מורכבת.גם טבלה טובה יכולה להיות בסיס משמעותי.

כי יש כלל אחד שקשה לעקוף:

אי אפשר לנהל סיכון שלא יודעים שהוא קיים.

לא כל AI הוא אותו סיכון

עוד טעות היא להחיל את אותם כללים על כל שימוש.

AI שמייצר תמונת רקע אינו שווה בסיכון למערכת שמסייעת לקבל החלטות לגבי מועמד לעבודה.

כלי שמסכם מאמר ציבורי אינו דומה ל-Agent שמקבל גישה ל-CRM ולמייל.

לכן AI Governance צריך להיות Risk-Based.

חמש שאלות בסיס להערכת סיכון

1. איזה מידע נכנס?
   ציבורי? פנימי? אישי? רגיש? קוד? קניין רוחני?
2. למה המערכת מחוברת?
   אין חיבור? SharePoint? CRM? Email? ERP?
3. מה AI עושה?
   כותב? מייעץ? מדרג? מחליט? מבצע פעולה?
4. מה יקרה אם הוא יטעה?
   טעות בטקסט שיווקי אינה דומה לטעות בהחלטת HR, פיננסים או בריאות.
5. מי מושפע?
   עובד? לקוח? מועמד? ציבור רחב?

מכאן ניתן לקבוע לדוגמה:

Low Risk: שימוש במידע ציבורי, ללא החלטה משמעותית.

Medium Risk: מידע פנימי, חיבור למערכות או שימוש בתהליכים עסקיים.

High Risk: מידע רגיש, החלטות משמעותיות, השפעה על אנשים או הרשאות רחבות.

המטרה אינה לייצר בירוקרטיה.

המטרה היא להשקיע את רמת הבקרה במקום שבו נמצא מרבית הסיכון.

ISO/IEC 42001: להפוך AI Governance למערכת ניהול

אם AI Governance נשמע מופשט, ISO/IEC 42001 נותן לו מסגרת ברורה.

זהו התקן הבינלאומי למערכת ניהול בינה מלאכותית – Artificial Intelligence Management System, או AIMS.

המשמעות שלו אינה "לעשות Audit ל-AI".

המשמעות היא לבנות מערכת ניהול.

כלומר:

• Scope
• מדיניות
• בעלי תפקידים
• יעדים
• הערכת סיכונים
• AI Impact Assessment
• בקרות
• ניהול ספקים
• Monitoring
• Audit
• Management Review
• Corrective Actions
• Continuous Improvement

זו בדיוק הסיבה שאנחנו רואים ב-ISO 42001 עוגן טבעי ל-AI Governance.

הוא מעביר את השיחה מ:

"באיזה AI אנחנו משתמשים?"

ל:

"איך הארגון מנהל את ה-AI לאורך זמן?"

ISO 42001, ISO 27001 ו-ISO 27701 – שלוש שכבות תקינה משלימות

חשוב להבין את החלוקה.

ISO/IEC 42001

מנהל את מערכת ה-AI ואת ה-Governance סביבה.

ISO/IEC 27001

מנהל את אבטחת המידע.

AI עדיין תלוי ב:

• זהויות
• הרשאות
• Cloud
• Data
• Logs
• ספקים
• Incident Management
• Risk Management

לכן ISO 27001 ממשיך להיות בסיס משמעותי מאוד.

ISO/IEC 27701

מוסיף את שכבת ניהול הפרטיות.

במיוחד כאשר AI מעבד מידע על:

• לקוחות
• עובדים
• מועמדים
• משתמשים
• או כל מידע אישי אחר

3 שכבות ה-compliance משלימות אחת את השניה

1. ISO 42001 – AI Management
2. ISO 27001 – Information Security Management
3. ISO 27701 – Privacy Information Management

בפועל, בארגון מוכן כאשר שלושת השכבות מתחברות.

יצירת קשר עם מומחי תקינה ורגולציה בתחום ה-AI

ומה עם NIST AI RMF?

מסגרת משלימה חשובה היא NIST AI Risk Management Framework.

ה-NIST מארגן את ניהול הסיכון סביב ארבע פונקציות:

• GOVERN – אחריות, תרבות, מדיניות ותהליכים
• MAP – הבנת ההקשר והשפעת ה-AI
• MEASURE – הערכת ומדידת הסיכון
• MANAGE – תיעדוף וטיפול

NIST גם פרסם Profile ייעודי ל-Generative AI.

נכון ל-2026, AI RMF 1.0 נמצא בעצמו בתהליך עדכון.

עבור ארגונים שכבר עובדים בגישת NIST, זה יכול להיות חיבור טבעי מאוד ל-AI Governance ול-Risk Management הקיים.

AI צריך גם Risk Register משלו

AI מייצר סיכונים שאינם רק Cybersecurity.

לדוגמה:

• Hallucination – יצירת מידע שגוי שנראה אמין.
• Bias – הטיה בתוצאות.
• Data Leakage – חשיפת מידע.
• Prompt Injection – ניסיון להשפיע על התנהגות המודל באמצעות Input זדוני.
• Excessive Agency – יכולת פעולה רחבה מדי.
• Privacy Risk – שימוש לא נכון במידע אישי.
• IP Risk – קניין רוחני וזכויות יוצרים.
• Model Drift -שינוי באיכות או בהתנהגות.
• Third-Party Dependency – תלות בספק חיצוני.
• Lack of Explainability – קושי להבין או להסביר החלטה.

מערכת יכולה להיות מאובטחת מבחינת Cyber ועדיין לייצר תוצאה עסקית בעייתית.

זו הסיבה ש-AI Risk Management צריך להסתכל מעבר לאבטחת המידע.

מי אחראי על AI Governance?

זו אחת השאלות החשובות ביותר.

האם זה:

• IT?
• CISO?
• DPO?
• Legal?
• Innovation?
• Data?
• Risk?

התשובה שלנו היא:

כולם מעורבים, אבל מישהו חייב להיות Owner.

• היחידה העסקית אחראית על ה-Use Case
• IT על המערכת והאינטגרציות
• CISO על אבטחה והרשאות
• DPO על מידע אישי
• Legal על דרישות משפטיות וחוזיות
• Risk / GRC על מסגרת הסיכון והבקרה
• והנהלה על Risk Appetite ועל הכרעה כאשר קיימים שיקולים מתנגשים

לכל שימוש משמעותי ב-AI צריך להיות Owner ברור.

אפשר להקים גם פורום AI Governance או ועדת סיכונים רוחבית.
אבל ועדה אינה תחליף לבעלות.

שלוש שאלות פשוטות עדיין עובדות מצוין:

1. מי אישר?
2. מי מנהל את הסיכון?
3. מי אחראי אם משהו משתבש?

Shadow AI הוא הסימפטום של Governance חסר

בדומה ל-SHADOW IT, אחד הסיכונים הגדולים ביותר נמצא דווקא מחוץ לפרויקטי AI הרשמיים.

Shadow AI

• עובד שמצא כלי חדש
• מנהל שמעלה מצגת לשירות חינמי "רק כדי לסכם"
• מפתח שמחבר API
• מחלקה שרוכשת SaaS בכרטיס אשראי ומעלה אליו
• עובד שמתחבר למערכות עם חשבונו אישיים

כל אחד מהאירועים נראה קטן, יחד הם יוצרים סביבת AI שלמה שהארגון אינו מכיר.

אבל Shadow AI אינו רק בעיית עובדים, לעיתים הוא סימפטום לכך שהארגון לא סיפק:

• כלים מאושרים
• מדיניות ברורה
• תהליך אישור מהיר
• הדרכה
• חלופה טובה מספיק

לכן המטרה אינה:

Shadow AI → No AI

אלא:

Shadow AI → Managed AI.

AI Agents משנים שוב את כללי המשחק

Generative AI לא רק מקבל מידע ומחזיר תשובה, AI Agent יכול גם לבצע פעולה.

לדוגמה:

• לקרוא מייל ולענות
• לפתוח CRM
• ליצור מסמך
• לשנות רשומה
• לשלוח הודעה
• להפעיל Workflow
• לקרוא מידע ממספר מערכות ולפעול על בסיסו.

כאן AI Governance מתחבר ישירות ל-Identity & Access Management.

צריך לדעת:

• איזו זהות יש ל-Agent?
• אילו הרשאות הוא קיבל?
• מי אישר אותן?
• האם מיושם Least Privilege?
• האם יש Expiration?
• האם אפשר לעצור אותו?
• האם הפעולות נרשמות?
• האם אפשר לשחזר שינוי?

ארגונים רגילים לנהל משתמשים אנושיים.

עכשיו הם צריכים להתחיל לנהל גם Non-Human Identities.

Human in the Loop הוא Control, לא סלוגן

הרבה מערכות AI מציינות שקיים Human Oversight.

אבל השאלה האמיתית היא:

מה האדם באמת עושה?

אם עובד מאשר אוטומטית כל המלצה שהמערכת מציגה, אין פיקוח משמעותי.

לכן צריך להגדיר:

• מתי נדרש Review.
• מה צריך לבדוק.
• מהי סמכות הבודק.
• מתי נדרש Escalation.
• מתי אסור לבצע פעולה אוטומטית.
• ומה רמת הידע הנדרשת.
• Human in the Loop צריך להיות בקרה מתוכננת ומדידה.

Data Classification הופך לתשתית של AI Governance

מדיניות שאומרת:

"אסור להעלות מידע רגיש ל-AI"

נשמעת הגיונית.

אבל היא עובדת רק אם העובד יודע מה נחשב "רגיש".

כאן Data Classification – סיווג מידע, הופך לחלק חשוב מה-Governance.

אפשר לדוגמה להגדיר:

• PUBLIC – מותר בכלים מאושרים.
• INTERNAL – מותר בסביבה ארגונית מאושרת.
• CONFIDENTIAL – דורש בקרות נוספות.
• RESTRICTED – אסור להזנה לכלי AI חיצוני ללא אישור פרטני.

כך מחברים מדיניות להתנהגות בפועל.

גם ספקי AI צריכים Governance

רוב הארגונים אינם מפתחים מודלים בעצמם.

הם קונים AI כשירות.

לכן כל AI Governance טוב חייב לכלול גם Third-Party Risk Management.

צריך להבין:

• מי הספק?
• מי מפעיל את המודל?
• מי הם ה-Subprocessors?
• איפה המידע נשמר?
• האם Prompts נשמרים?
• האם Outputs נשמרים?
• האם המידע משמש לאימון?
• מהי מדיניות Retention?
• אילו Logs קיימים?
• כיצד מדווחים על Incident?
• מה קורה בסיום ההתקשרות?
• ומה קורה כאשר הספק משנה Model Version?

הנקודה האחרונה חשובה.

מערכת AI יכולה להשתנות גם אם הארגון עצמו לא שינה דבר.

לכן שינוי מודל, שינוי Use Case, הוספת Data Source או הרחבת הרשאה צריכים להיות Trigger ל-Review.

איך נראה AI Governance בפועל? 12 אבני יסוד של ניהול בינה מלאכותית בארגון.

אנחנו ממליצים להתחיל ממסגרת פשוטה וברורה.

1. AI Governance Charter

הגדרת בעלות, אחריות וסמכויות.

2. AI Inventory

מיפוי המערכות, המודלים, Agents וה-Use Cases.

3. AI Acceptable Use Policy

מה מותר, מה אסור ומה דורש אישור.

4. Risk Classification

חלוקת שימושים לפי רמת סיכון.

5. AI Use Case Assessment

תהליך מסודר לבחינת שימוש חדש.

6. Security Review

מידע, IAM, הרשאות, APIs, Integrations ו-Logs.

7. Privacy Review

מידע אישי, Privacy by Design ו-DPIA/PIA במקרים הרלוונטיים.

8. Vendor Assessment

בדיקת ספק, חוזים, Subprocessors ו-Retention.

9. Human Oversight

הגדרת נקודות הבקרה האנושיות.

10. AI Literacy

הדרכת עובדים ומנהלים.

11. Monitoring & Evidence

תיעוד, Metrics, חריגים ובקרות.

12. Management Review & Continuous Improvement

בדיקה תקופתית ושיפור.

לא כל ארגון צריך להגיע לכול ביום הראשון.

אבל כדאי לדעת מהו ה-Target State.

Evidence: איך מוכיחים שה-Governance באמת עובד?

זה אחד הנושאים החשובים ביותר.

מדיניות AI אינה Evidence לכך שה-AI מנוהל.

אם הארגון אומר שיש לו AI Governance, הוא צריך להיות מסוגל להציג:

• AI Inventory
• Risk Assessments
• Owners
• Use Case Approvals
• Vendor Assessments
• DPIA/PIA כאשר נדרש
• רשומות הדרכה
• Audit Logs
• חריגים
• Corrective Actions
• Review Periodic
• Management Decisions
• מדדי שימוש

וזה מתחבר ישירות לתפיסה רחבה יותר של GRC ו-Continuous Compliance:

לא מספיק להגדיר בקרה. צריך לדעת שהיא פועלת.

AI Governance חייב להיות Continuous

AI משתנה מהר מדי בשביל Governance שנבדק פעם בשנה.

• כלים מתחלפים
• מודלים משתנים
• Agents מקבלים הרשאות
• ספקי SaaS מוסיפים AI
• עובדים מתחילים להשתמש בכלים חדשים
• והרגולציה ממשיכה להתפתח

לכן צריך לעבוד במחזור מתמשך:

Discover → Assess → Approve → Monitor → Review → Improve

זו בדיוק התפיסה שמוכרת ממערכות ניהול כמו ISO 27001 ו-ISO 42001.

Governance אינו Event – הוא Process.

מאמר בנושא Continuous Compliance: המטרה היא ביטחון, הדרך היא תקינה

מה אנחנו ממליצים לעשות מחר בבוקר?

לא להתחיל מפרויקט של שנה.

להתחיל מתמונה אמיתית.

1. למפות את כלי ה-AI הקיימים
2. לזהות Shadow AI
3. לבנות AI Inventory
4. להגדיר Owner לכל שימוש משמעותי
5. לקבוע Risk Classification
6. להגדיר מה מותר ואסור מבחינת מידע
7. לבדוק ספקים
8. לבחון Privacy ו-Security
9. להגדיר תהליך אישור ל-Use Cases חדשים
10. הדרכת עובדים למודעות אבטחת מידע בדגש על בינה מלכותית וכלי AI
11. לייצר Evidence
12. ורק לאחר מכן להחליט עד כמה רוצים להתקדם ל-ISO 42001 ולמערכת AIMS פורמלית.

רק אחר כך מחליטים עד כמה רוצים להתקדם למסגרת פורמלית כמו ISO/IEC 42001.
המומחים שלנו כאן לתת לכם ייעוץ ראשוני לגבי הדרישות בארגון שלכם.
יצירת קשר עם מומחי אבטחת מידע לבינה מלאכותי באינפוגארד.

איך אנחנו באינפוגארד מנהלים תהליך?

באינפוגארד אנחנו עובדים בדיוק בנקודת המפגש שבין:

AI, Cybersecurity, Privacy, Risk, GRC ו-Compliance.

אנחנו מסייעים לארגונים לבנות AI Governance באופן פרקטי:

• מיפוי כלי AI ו-Shadow AI
• AI Risk Assessments
• בניית Policy
• ניהול ספקים
• בחינת פרטיות ו-DPIA
• בדיקת הרשאות ואינטגרציות
• שילוב עם ISO 27001 ו-ISO 27701
• ליווי ויישום ISO 42001
• שירותי CISO ו-DPO
• AI Literacy והדרכות
• ביקורת, Evidence ו-Continuous Compliance

המטרה היא לא להוסיף לארגון עוד שכבת בירוקרטיה.
המטרה היא לבנות מסגרת שמאפשרת להגיד כן מהר יותר ובביטחון.

החדשנות כבר כאן. עכשיו צריך לבנות לה מערכת ניהול

AI Governance אינו נועד להגן על הארגון מפני חדשנות – הוא נועד לאפשר לארגון לחדש מבלי לאבד שליטה בדרך.

AI Governance נשמע לפעמים כמו עוד שכבת בירוקרטיה – אנחנו מסתכלים עליו הפוך.

ככל שה-AI הופך עצמאי יותר, מחובר יותר למידע ומעורב יותר בהחלטות, כך הארגון צריך פחות אילתורים ויותר בהירות.

• מי רשאי לעשות מה.
• איזה מידע מותר לחשוף.
• איזה סיכון אנחנו מוכנים לקחת.
• מתי נדרש אדם בתהליך.
• ומי עומד מאחורי ההחלטה.

הארגונים שיצליחו עם AI לא יהיו בהכרח אלה שאימצו אותו ראשונים, הם יהיו אלה שידעו לאמץ אותו בצורה בטוחה ומושכלת.

כי בסופו של דבר, AI Governance אינו נועד להגן על הארגון מפני חדשנות. הוא נועד לאפשר לארגון לחדש בביטחון.

השינוי שהארגון צריך לעשות אינו:

No AI → AI

אלא:

Unmanaged AI → Managed AI

• מכלים שלא יודעים שקיימים – ל-AI Inventory
• מ-Shadow AI – לשימוש מאושר
• ממדיניות כללית – ל-Risk Classification
• מהרשאות רחבות – ל-Least Privilege
• מהחלטות לא מתועדות – ל-Evidence
• ומבדיקה שנתית – ל-Continuous Governance

המטרה שלנו לאפשר להרחיב את השימוש בAI בלי לאבד שליטה על הסיכון, המידע והאחריות.

האם ה-AI בארגון שלכם באמת מנוהל?

אם אתם כבר משתמשים ב-AI, מטמיעים Copilot, מחברים Agents או מתחילים להתמודד עם Shadow AI, עכשיו הוא הזמן לבנות את מסגרת הניהול סביבם.

באינפוגארד אנחנו מסייעים להפוך שימוש מפוזר ב-AI למערכת ניהול מסודרת, מבוססת Risk, Privacy, Security ו-Evidence.

דברו איתנו על AI Governance, ISO 42001 וניהול סיכוני AI בארגון.
יצירת קשר עם מומחי אבטחת המידע של אינפוגארד

אנחנו באינפוגארד מאמינים שכל ארגון חייב נדרש לבחון את צרכיו, הסיכונים והדרישות החלות עליו באמצעות אנשי מקצוע מתאימים. ואנחנו באינפוגארד כאן ללוות אתכם.

המידע המוצג במאמר זה נועד למטרות מידע והעשרה בלבד ואינו מהווה תחליף לייעוץ מקצועי, רגולטורי, משפטי, סייבר, אבטחת מידע, הגנת הפרטיות או ייעוץ טכנולוגי.

המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך על ידי רועי קיש, אבטחת מידע, סייבר ומנהל השיווק של קבוצת חברות עידור (Messagent, Infoguard, Idornext).

יצירת קשר עם מומחי אבטחת המידע של אינפוגארד