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

מה כוללת כל בדיקה טכנית

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

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

שש שאלות ייחודיות ל-AI

1. למי שייכות הזכויות על הקוד

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

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

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

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

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

4. עד כמה המוצר תלוי בפלטפורמה

מוצר שנבנה ב-Lovable או ב-Bolt נשען לעיתים קרובות על שילוב של הפלטפורמה, Supabase וכמה שירותי ענן. השאלה היא אם אפשר לבנות אותו מהמאגר בלי הפלטפורמה, למי שייכים החשבונות ומה יקרה אם הפלטפורמה תשנה את התנאים.

5. כמה עולה AI למשתמש אחד

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

6. האם יש אדם שמבין את המערכת

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

מה המשקיע או הרוכש מקבל

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

איך הבדיקה מתנהלת

1. גישת קריאה למאגר, רשימת שירותים וחשבונות, תיאור המוצר ותוכנית הצמיחה.
2. שיחה עם מי שבנה את המערכת: איך היא בנויה, מה עשה ה-AI ומה עשו אנשים.
3. בדיקת הקוד, התלויות, הגישה לנתונים והתשתית.
4. דוח וסקירה עם המשקיע או הרוכש.

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

שאלות נפוצות

במה בדיקת נאותות של מוצר AI שונה מבדיקה רגילה?

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

האם יש זכויות על קוד שנכתב ב-AI?

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

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

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

מה נמצא הכי הרבה בבדיקות כאלה?

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

מי מזמין את הבדיקה?

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