בינה מלאכותית כבר נכנסה למערכות האיכות – בין אם הארגון אישר את זה ובין אם לא.

אנשי QA משתמשים ב-GPT או מודלי שפה אחרים לסיכום חריגות, כתיבת טיוטות CAPA, עזרה בהכנת תשובות לביקורת, ניתוח מגמות ספקים, ועוד.

 

הבעיה היא לא “האם מותר להשתמש ב-AI”.

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

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

​
למה AI הוא אתגר ייחודי בתוך מערכת איכות
רוב כלי האיכות בנויים על עיקרון פשוט: תהליך --> תוצאה --> תיעוד --> בדיקה.
בינה מלאכותית שוברת את המשוואה הזו בשלושה אופנים:

1. שונות בתוצאות (Non-Deterministic Outputs)
   אותו קלט יכול להחזיר תשובות שונות. במערכת איכות זה לא אמור לקרות, היות ואנחנו מעוניינים בעקביות, קריטריונים ברורים של קבלה/דחייה וכמובן ראיות מוחשיות שתומכות בהחלטה.

2. השפעה על החלטות
   גם אם כולם אומרים “זה רק כלי עזר”, בפועל – אנשים נשענים על הבינה המלאכותית. AI שמסווג תלונות, מציע Root Cause, או מנסח CAPA יכול לשנות החלטות, קצב, ותיעדוף. היא עלולה להשפיע על שיקול הדעת של המשתמשים בעיקר בטווח הארוך.

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

​
“AI בתוך QMS” זה לא מוצר – זה אוסף Use Cases
הרבה ארגונים נכנסים לזה הפוך: “בואו נכניס AI למערכת האיכות”.
זה משפט יפה, אבל הוא לא תוכנית עבודה.
​
הטמעה נכונה מתחילה ב־רשימת Use Cases מוגדרת, ואז מסווגים אותם לפי סיכון ותועלת.
 
להלן דוגמאות ל־Use Cases שכמעט תמיד עולים בארגונים (ועובדים טוב כשהם נשלטים):
​

Use Case 1: עוזר כתיבה ותיעוד (Low–Medium Risk)

• ניסוח טיוטות CAPA / Deviation

• שיפור ניסוח פרוצדורות והפיכת שפה למסודרת יותר

• יצירת טיוטות תגובה לביקורת (תחת בקרה)

• יצירת שאלונים/מדריכי עבודה להכשרת עובדים

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

• מגדירים שה־AI מייצר טיוטה בלבד

• מחייבים בדיקת עובדות מול מקור (נהלים, רשומות, תקן)

• מגדירים תבניות: כותבים פרומפטים מאחורי כלי העזר הזה שהם "חסינים רגולטורית", עם הגבלות ברורות והגדרת הSCOPE של אותו עוזר AI. מה מותר להציע ומה אסור (לדוגמה: אסור להמציא נתונים / אסור לטעון עמידה בדרישה בלי ראיה)

​
​
Use Case 2: עוזר חיפוש ידע בתוך תיעוד איכות (Medium Risk)

• חיפוש בתוך נהלים, טפסים, מדיניות, ותבניות

• הפניה לסעיפים רלוונטיים

• סיכום מהיר של דרישות מתוך מסמכים פנימיים

​
מה היתרון: מקצר משמעותית זמן “איפה כתוב מה” בתוך מערכת מסמכים גדולה.
איפה הסיכון: תשובות עם ביטחון גבוה אבל עם ציטוט שגוי / פרשנות לא נכונה.
איך שולטים בזה בפועל:

• מחייבים “תשובה עם הפניות” (קישור למסמך, סעיף, גרסה)

• אם אין מקור הAI חייב להגיד “לא נמצא במאגר”

• רמת הרשאות: לא כל עובד רואה כל מסמך

• ​

Use Case 3: ניתוח מגמות איכות (Medium–High Risk)
דוגמאות אמיתיות:

• ניתוח תלונות: קיבוץ לפי מוצר/כשל/שוק, זיהוי טרנדים

• ניתוח ספקים: שילוב כמות חריגות + חומרה + מגמת זמן

• ניתוח NCR: האם חוזר אותו כשל? האם יש “תבנית” שמפספסים?

​
מה היתרון: AI טוב בזיהוי תבניות, במיוחד כשיש הרבה טקסט חופשי ועוזר למצוא את ה"נקודות העיוורות" שעוזרות לנו להיות פרו-אקטיבים ולא רק מכבי שריפות.
איפה הסיכון: הטיות, סיווגים שגויים, “תובנות” שנשמעות הגיוניות אבל לא מבוססות.
איך שולטים בזה בפועל:

• מגדירים שה־AI מספק “Hypotheses” ולא “Conclusions”

• דורשים Outliers + הסבר למה

• משלבים בדיקה ידנית למדגם (sampling) כדי לוודא שהסיווגים לא מתדרדרים

​
Use Case 4: סיוע בהחלטות איכות (High Risk)

כאן נכנסים אזורים רגישים:

• המלצה אם לפתוח CAPA או לא

• המלצה על Root Cause

• המלצה על פעולות מתקנות

• “אישור” תקינות מסמך/תיק טכני/תיק איכות

​
מה היתרון: יכול להאיץ מאוד תהליכים ולשפר עקביות.
איפה הסיכון: זה כבר נוגע בהכרעות איכות – וזה מקום שבו ביקורת תשאל הכי הרבה שאלות.
איך שולטים בזה בפועל:

• AI לא “מאשר”, הוא מציע אפשרויות

• חובה Human Approval מתועד

• חובה שקיפות מלאה לאיך הAI חושב ולפי איזו לוגיקה הגדרנו לו לעבוד.

• הגדרות ברורות: מה תנאי סף להצעה, ומה מנגנון “עצירה” (stop points)

​
שלב ההטמעה שאף אחד לא עושה נכון:
סיווג סיכון לפני “בואו נרוץ”
 
בכל הטמעה אנחנו מתחילים מאותו מסמך קצר (עמוד–שניים), שמונע 80% מהטעויות:
​
1) Intended Use – מה בדיוק ה-AI עושה
 “מסכם deviation על בסיס שדות X,Y,Z ומציע 3 כיווני RCA אפשריים”.
​
2) Out of Scope – מה אסור לו לעשות
דוגמאות:

• אסור להמציא נתונים

• אסור להחליף החלטה של QA

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

• אסור לייצר מסמכים רשמיים בלי אישור אנוש

​
3) Impact Assessment – מה קורה אם הוא טועה
האם טעות יכולה:

• להשפיע על שחרור מוצר?

• להשפיע על דיווח רגולטורי?

• להסתיר מגמת כשל?

• לגרום לפעולה מתקנת לא נכונה?

לפי זה מסווגים Low / Medium / High, ומשם נגזרת רמת הבקרה.
​
מה זה “Validation” ל-AI בתוך מערכת איכות (ולמה IQ/OQ/PQ קלאסי לא מספיק)
 
כשל נפוץ הוא לקחת תבנית IQ/OQ/PQ קלאסית ולנסות “להלביש” עליה AI.כאילו מדובר במערכת דטרמיניסטית שמחזירה תמיד את אותה תוצאה לאותו קלט. בפועל, הניסיון הזה כמעט תמיד מוביל לאחד משני קצוות בעייתיים:
​
בקצה הראשון, הארגון מנסה להוכיח יציבות מוחלטת של התוצר.
בודקים שוב ושוב את אותו תרחיש, מצפים לאותה תשובה, וכשהתוצאה משתנה זה נתפס כ”כשל”. התוצאה היא ולידציה שלא מצליחה להיסגר, או מסמך תיאורטי שמנותק מהתנהגות הכלי בפועל.
​
בקצה השני, הארגון מוותר על אימות בכלל.
מכריז ש”זה רק כלי עזר”, לא מגדיר קריטריונים, ולא בודק התנהגות. במקרה הזה, הבעיה לא תופיע ביום ההשקה אלא בביקורת הראשונה, כשאין דרך להסביר מה נבדק, מה אושר, ועל סמך מה.
 
אז מה כן בודקים כשמאמתים AI בתוך מערכת איכות?
בניגוד למערכות קלאסיות, ב-AI אנחנו לא מחפשים זהות מלאה בין התוצאות. אנחנו מחפשים התנהגות צפויה בתוך גבולות מוגדרים מראש.
ולידציה טובה ל-AI תענה על השאלה: "האם המערכת מתנהגת בצורה עקבית ובטוחה גם כשהקלט לא מושלם וגם כשהתשובה לא זהה בכל פעם?"
​
איך זה נראה בפועל:

• מגדירים תרחישי בדיקה (Use Case Tests), הבדיקות מבוססות על מצבי עבודה אמיתיים (חריגה מתועדת היטב, חריגה עם מידע חלקי, חריגה עם סתירות בין שדות, מקרה שבו אין מספיק מידע כדי להסיק מסקנה ועוד)

• מגדירים Acceptance Criteria שלא דורשים “אותו טקסט”, אלא:

  • האם מבנה התשובה נשמר (חלוקה לבעיה / ניתוח / הצעה)

  • האם אין המצאות עובדתיות או קביעות שלא נתמכות בקלט

  • האם הטון תואם שיח רגולטורי (מסויג, לא החלטי מדי)

  • האם המערכת מציינת אי־ודאות כאשר חסר מידע

  • האם המסקנות נשארות בתוך תחום הסמכות שהוגדר

• בונים סט בדיקות שמכסה:

  • מקרים פשוטים

  • מקרים גבוליים

  • מקרים “מלוכלכים” (נתונים חסרים, ניסוח לא ברור, סתירות)

​
דוגמה לקריטריון קבלה (ל-CAPA Drafting)
בפרויקט שבו AI שימש לעזרה בניסוח טיוטות CAPA, הוגדרו קריטריונים ברורים כגון:
המערכת חייבת:

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

• להימנע מקביעה חד־משמעית של Root Cause ללא ראיות בקלט

• להציע לפחות שני כיווני RCA אפשריים, ולא כיוון יחיד

• לכלול סעיף “Verification of Effectiveness” כתנאי קבוע

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

• להימנע מהצהרות על עמידה רגולטורית או סגירת חריגה

המבחן היה: "האם ההתנהגות חוזרת על עצמה בצורה אחראית, גם כשהתוכן משתנה?”
​
זיכרו, המבקרים לא מבקשים שלמות, הם מחפשים הבנה שליטה ושקיפות. אפשר להראות מה נבדק? האם אפשר להסביר למה שונות בתוצאות היא צפויה? האם תוכלו לתאר לו מהם גבולות השימוש? והכי חשוב: האם אפשר להראות שאדם תמיד נשאר מקבל ההחלטה?
​
בקרות תפעוליות שחייבות להיות אחרי ההשקה (לא רק “בדיקה פעם אחת”)
AI משתנה. עובדים משתנים. דפוסי שימוש משתנים. הטמעה של AI לא מסתיימת ביום שסיימנו ולידציה. בניגוד לתוכנה קלאסית, בינה מלאכותית היא מערכת חיה:
המודל מתעדכן, המשתמשים לומדים להיעזר בו ודפוסי השימוש משתנים עם הזמן.
בלי בקרות תפעוליות שוטפות, ארגון עלול לגלות באיחור שה-AI כבר משמש בפועל לתהליכים שמעולם לא אושרו או שהוא משפיע על החלטות איכות בצורה שלא תוכננה.
לכן אנחנו מגדירים בקרות שוטפות:
​
ניטור שימוש: להבין איך הכלי באמת משמש
השלב הראשון הוא לבדוק התנהגות, אנחנו נשאל באופן שוטף:

• מי משתמש? באיזה תהליך? באיזה תדירות?

• האם יש Use Cases הפכו “ברירת מחדל” בלי אישור?

המטרה המרכזית של הניטור היא לזהות מצבים שבהם: 

• Use Case שהוגדר כניסוי הופך בפועל לברירת מחדל

• עובדים מתחילים להיעזר ב-AI גם בתהליכים שלא אושרו

• הכלי “גולש” לאזורים רגישים יותר בלי שהארגון שם לב

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

• שיעור תשובות שנדחו/נערכו משמעותית

• סוגי טעויות חוזרות

בנוסף, אנחנו מסווגים טעויות חוזרות לפי סוג למשל: המצאות, טון רגולטורי שגוי, החמצת סיכונים
המטרה אינה לצפות לאפס טעויות, אנחנו רוצים לזהות מגמות שמעידות על שחיקה באיכות או שימוש לא נכון.
​
טריגרים לרה־וולידציה: מתי עוצרים ובודקים מחדש?
רה-וולידציה מופעלת על בסיס טריגרים ברורים מתועדים ומוסכמים מראש. היא אינה אירוע שרירותי.
דוגמאות לטריגרים שכיחים:

• שינוי מודל / גרסה / ספק מודל השפה

• שינוי מהותי בפרומפטים או בלוגיקה העסקית (כן, גם זה שינוי)

• שינוי בנהלים שעליהם ה-AI נשען

• עליה בטעויות מסוג מסויים מעל הסף המותר

• הרחבת השימוש לUse Cases חדש או רגיש יותר

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

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

• האם קיימות הרשאות לפי תפקיד, כך שלא כל משתמש נחשף לאותו מידע או לאותם יכולות

• האם קיימת הפרדה ברורה בין סביבת ניסוי (למידה, בדיקות) לבין סביבת עבודה רשמית

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

 
אלה הן בדיוק השאלות שמבקר ישאל כאשר AI נוגע בתיעוד איכות, בקבלת החלטות, או במידע רגיש.
​​
קודם כל: מי אמון על הנושא?
אחת הטעויות הנפוצות היא לחשוב שזה “בעיה של IT” או “בעיה של אבטחת מידע”.
בפועל, הטמעת AI במערכת איכות יושבת בין כמה בעלי תפקידים, וכל אחד מהם אחראי לחלק אחר בפאזל. בדרך כלל החלוקה הנכונה נראית כך:

• QA / RA – אחראים להגדיר מה מותר ומה אסור מבחינת שימוש, תיעוד, והשפעה על החלטות איכות

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

• הנהלה / בעלי תהליך – אחראים לאשר שימוש, לקבל סיכון מודע, ולהגדיר סדרי עדיפויות

• משתמשי קצה – אחראים לפעול לפי ההנחיות, ולא “לאלתר” שימושים חדשים

כמו בכל פרויקט רציני, הבעיה מתחילה כשאין Owner ברור ואז אף אחד לא באמת אחראי.
​
מעבר למדיניות והגדרות שימוש, הטמעת AI במערכת איכות מחייבת בדיקות טכניות בסיסיות.
לא מדובר בארכיטקטורת סייבר מורכבת אלא בכמה שאלות מפתח שכל ארגון רגולטורי חייב לדעת לענות עליהן.
​איפה הנתונים נשמרים האם המידע נשלח מחוץ לארגון, לאיזה איזור גיאוגרפי, האם נתונים נשמרים צורך אימון או נמחקים לאחר שימוש, האם קיימת החייבות חוזית, גם אם מידע "רק עובר במערכת" מבחינת הרגולציה זה עדיין שימוש בנתונים
הצפנת מידע: האם נתונים מוצפנים בשעת שליחה, האם קיימת הצפנה גם בצד השרת, ומי מנהל את מפתחות ההצפנה (הארגון או ספק חיצוני?)
ניהול זהויות והרשאות: האם קיימת הזדהות משתמשים? האם ניתן להגביל שימוש לפי תפקיד? מי יכול לראות או להזין מידע?
הפרדה בין סביבות: האם יש סביבת טסטים, האם יש הפרדה טכנית בין הטסטים לנתונים אמיתיים, האם ניתן למנוע שמידע מסביבת הטסט יזלוג לסביבה האמיתית?
לוגים וAUTDIT TRAIL: האם ניתן לשחזר תוצרים בתהליכי איכות? מי השתמש בכלי, מתי ולצורך מה, ומה הפלט שהתקבל. (לא תמיד צריך לשמור את כל התוכן אבל חייבת להיות יכולת להסביר בדיעבד שימוש בכלי)
​
איך מתחילים נכון (המלצה פרקטית)
אם הארגון שלכם חדש בנושא, אנחנו ממליצים להתחיל ב־2 Use Cases:

1. עוזר כתיבה ותיעוד (טיוטות בלבד, עם בקרה)

2. חיפוש ידע בתוך מסמכים פנימיים (עם מקורות והפניות)

אלה Use Cases שמביאים ROI מהר, עם סיכון נשלט, ונותנים בסיס לבנות עליו governance ו-validation.
​
סיכום
AI במערכת איכות יכול להיות יתרון תחרותי אמיתי:
קיצור זמני תגובה, שיפור עקביות, זיהוי תבניות, והפחתת עומס בירוקרטי.
אבל בלי מסגרת – הוא יוצר “מערכת איכות מקבילה” שאף אחד לא באמת שולט בה.
וזה בדיוק מה שמייצר חוב רגולטורי וממצאים.
​
רוצים לבדוק איפה אתם עומדים?
אם אתם כבר משתמשים ב-AI (או שוקלים להתחיל), אפשר לבצע Assessment קצר שממפה:

• Use Cases בפועל

• סיכון רגולטורי

• מה דורש בקרה/ולידציה

• ותוכנית הטמעה בשלבים (עם Quick Wins)

דברו איתנו ונגדיר יחד את המסלול הנכון – כזה שמייצר יעילות בלי להמר על האיכות.
​