Μέχρι πριν από λίγα χρόνια η απάντηση στο ερώτημα "ποιος έγραψε αυτόν τον κώδικα;" ήταν σχετικά απλή. Μπορούσες να δείξεις τον προγραμματιστή, την ομάδα ή το software house που ήταν υπεύθυνο για ένα συγκεκριμένο module.
Σήμερα η κατάσταση μοιάζει εντελώς διαφορετική.
Ένα μέρος του κώδικα μπορεί να γραφτεί χειροκίνητα. Ένα άλλο να το δημιουργήσει το Copilot. Ένα επόμενο να το φτιάξει ένας agent προγραμματισμού. Άλλο να αντληθεί από βιβλιοθήκη open source. Κάποιο άλλο να είναι εξάρτηση εξωτερικού πακέτου. Σε αυτά προστίθενται APIs, υπηρεσίες cloud, έτοιμα components, frameworks και εργαλεία που παρέχονται από διαδοχικές εταιρείες.
Το σύστημα λειτουργεί. Αλλά ξέρεις πραγματικά, από τι έχει κατασκευαστεί;
Ο κώδικας που δημιουργείται από την AI δεν εμφανίζεται στο κενό
Η ανάπτυξη εργαλείων AI για προγραμματισμό αλλάζει όχι μόνο τον τρόπο συγγραφής λογισμικού. Αλλάζει επίσης τη δομή της ευθύνης για τον κώδικα.
Ένας προγραμματιστής μπορεί σήμερα να περιγράψει μια εργασία σε έναν agent και στη συνέχεια να λάβει έτοιμη συνάρτηση, module, δοκιμές, ρυθμίσεις ή ακόμη και πρόταση αρχιτεκτονικών αλλαγών. Αυτό είναι τεράστιο επιτάχυνση της δουλειάς.
Το πρόβλημα αρχίζει όταν αντιμετωπίζουμε τον παραγόμενο κώδικα ως "κώδικα από το πουθενά".
Η AI δεν δημιουργεί κώδικα αποκομμένο από ολόκληρο το προγραμματιστικό οικοσύστημα. Τα μοντέλα εκπαιδεύονται σε τεράστια σύνολα δεδομένων, ενώ το παραγόμενο απόσπασμα μπορεί να μοιάζει με υπάρχουσες λύσεις, πρότυπα ή δημόσια διαθέσιμο κώδικα. Ακριβώς γι' αυτό το ζήτημα της προέλευσης του κώδικα, των αδειών χρήσης και της ευθύνης γίνεται όλο και πιο σημαντικό.
Αυτό δεν σημαίνει αυτόματα ότι κάθε τμήμα κώδικα που δημιουργείται από AI παραβιάζει κάποιου την άδεια. Σημαίνει όμως ότι ο οργανισμός που χρησιμοποιεί AI στη διαδικασία παραγωγής λογισμικού θα πρέπει να αντιμετωπίζει την προέλευση και την επαλήθευση του κώδικα ως στοιχείο της μηχανικής διαδικασίας και όχι ως νομική περιέργεια.
Αυτό δεν είναι πλέον μόνο θεωρία
Στις 16 Σεπτεμβρίου 2026 το Εφετείο του 9ου Κυκλώματος έκρινε μέρος της υπόθεσης Doe v. GitHub, στην οποία προγραμματιστές κατηγορούσαν το GitHub, τη Microsoft και οντότητες της OpenAI, μεταξύ άλλων, για χρήση δημοσίως διαθέσιμου κώδικα από το GitHub κατά τη δημιουργία και την εκπαίδευση εργαλείων όπως το Copilot και το Codex.
Ένα από τα αιτήματα αφορούσε τον DMCA και πληροφορίες περί πνευματικών δικαιωμάτων. Το δικαστήριο επικύρωσε την απόρριψη αυτής της συγκεκριμένης κατηγορίας. Ταυτόχρονα, η υπόθεση περιλαμβάνει και άλλα ζητήματα που σχετίζονται με τα πνευματικά δικαιώματα και τις άδειες open source.
Αυτό είναι σημαντικό όχι επειδή μία απόφαση δίνει μια απλή απάντηση στο ερώτημα "μπορείς να χρησιμοποιήσεις κώδικα από AI".
Δεν δίνει.
Πιο σημαντικό είναι ότι η διαμάχη δείχνει ένα ευρύτερο πρόβλημα: στον κόσμο της AI το όριο ανάμεσα στον κώδικα που γράφτηκε από άνθρωπο, στον κώδικα που παράχθηκε από μοντέλο και στον κώδικα που προέρχεται από το υπάρχον οικοσύστημα λογισμικού γίνεται όλο και πιο δύσκολο να ιχνηλατηθεί.
Και για τις εταιρείες που δημιουργούν λογισμικό αυτό σημαίνει την ανάγκη για καλύτερη διαχείριση αυτής της διαδικασίας.
Software supply chain, δηλαδή το σύστημά σου έχει πολύ περισσότερους "συγγραφείς"
Στην ασφάλεια λογισμικού εδώ και χρόνια χρησιμοποιείται η έννοια software supply chain - η αλυσίδα εφοδιασμού λογισμικού.
Αυτά είναι όλα τα components, τα εργαλεία, οι βιβλιοθήκες, οι εξαρτήσεις και οι διαδικασίες που συμμετέχουν στη δημιουργία του τελικού προϊόντος.
Το NIST επισημαίνει σε αυτό το πλαίσιο, μεταξύ άλλων, την ανάγκη διαχείρισης της προέλευσης των components, ελέγχου των εξαρτήσεων open source, παρακολούθησης των ευπαθειών και χρήσης του SBOM, δηλαδή του Software Bill of Materials.
Το SBOM μπορεί, πολύ απλουστευμένα, να συγκριθεί με μια λίστα συστατικών του προϊόντος.
Δεν λέει μόνο "έχουμε μια εφαρμογή". Δείχνει ποια components βρίσκονται μέσα.
Για παράδειγμα:
- framework της εφαρμογής,
- εξωτερικές βιβλιοθήκες,
- εκδόσεις επιμέρους πακέτων,
- components open source,
- έμμεσες εξαρτήσεις,
- στοιχεία που παρέχονται από εξωτερικούς προμηθευτές.
Χάρη σε αυτό, όταν εμφανιστεί μια ευπάθεια σε μια συγκεκριμένη βιβλιοθήκη, μπορείς πιο γρήγορα να ελέγξεις ποια συστήματα τη χρησιμοποιούν.
Το NIST επισημαίνει επίσης το provenance, δηλαδή τη δυνατότητα ιχνηλάτησης της προέλευσης των στοιχείων λογισμικού.
Και ακριβώς εδώ η AI προσθέτει ένα νέο επίπεδο πολυπλοκότητας.
Γιατί στο υπάρχον chain προστίθεται άλλος ένας τρόπος δημιουργίας κώδικα.
Φαντάσου ένα τυπικό business system
Το 40% του κώδικα το έγραψε η ομάδα.
Το 20% δημιουργήθηκε με τη βοήθεια AI.
Τα επόμενα αποσπάσματα τα δημιούργησε ένας agent.
Μερικές βιβλιοθήκες προέρχονται από open source.
Ένα μέρος των εξαρτήσεων προστέθηκε από το framework.
Το σύστημα χρησιμοποιεί API εξωτερικού παρόχου.
Ένα component προέρχεται από πακέτο που κανείς δεν έχει ενημερώσει εδώ και δύο χρόνια.
Και η τεκμηρίωση των εξαρτήσεων;
Είναι κάπου στο αποθετήριο.
Ή δεν υπάρχει.
Το σύστημα λειτουργεί...
Και ακριβώς γι' αυτό το πρόβλημα είναι αόρατο. Μέχρι να συμβεί κάτι.
Και μετά εμφανίζεται μια ευπάθεια
Ας υποθέσουμε ότι σε μία από τις βιβλιοθήκες εντοπίζεται σοβαρό κενό ασφαλείας.
Το ερώτημα είναι: Ξέρεις αν το σύστημά σου τη χρησιμοποιεί;
Αν έχεις οργανωμένο μητρώο εξαρτήσεων, η απάντηση μπορεί να είναι υπόθεση λεπτών.
Αν δεν έχεις, ξεκινά χειροκίνητη αναζήτηση στα αποθετήρια, επικοινωνία με τους προγραμματιστές, έλεγχος περιβαλλόντων, εκδόσεων πακέτων και έμμεσων εξαρτήσεων.
Και τώρα ας προσθέσουμε σε αυτό κώδικα που δημιουργήθηκε από AI.
Ξέρουμε ποιο τμήμα δημιουργήθηκε με ποιο εργαλείο;
Έγινε code review;
Καλύφθηκε ο κώδικας με δοκιμές;
Ελέγχθηκαν οι εξαρτήσεις;
Έλεγξε κάποιος την άδεια χρήσης του component;
Μπορεί να αναπαραχθεί η διαδικασία από την οποία προέκυψε ένα συγκεκριμένο τμήμα;
Αυτές δεν είναι πια ερωτήσεις μόνο για τον προγραμματιστή.
Είναι ερωτήσεις που αφορούν τη διαχείριση τεχνολογικού κινδύνου της εταιρείας.
Το μεγαλύτερο πρόβλημα δεν είναι η AI. Είναι η έλλειψη διαδικασίας
Θα ήταν εύκολο να γίνει από αυτό το άρθρο μια προειδοποίηση κατά της τεχνητής νοημοσύνης.
Θα ήταν όμως υπερβολικά απλό συμπέρασμα.
Η AI μπορεί να βελτιώσει πολύ την παραγωγικότητα της ομάδας ανάπτυξης.
Το πρόβλημα εμφανίζεται όταν η εταιρεία αυξάνει τον ρυθμό παραγωγής κώδικα, αλλά δεν αυξάνει ταυτόχρονα τον έλεγχο πάνω σε αυτόν τον κώδικα.
Είναι λίγο σαν μια βιομηχανία να παρήγαγε ξαφνικά δέκα φορές περισσότερα στοιχεία, αλλά να μην αύξανε τον ποιοτικό έλεγχο, την καταγραφή υλικών ή τον έλεγχο προμηθευτών.
Σε ένα software house αντίστοιχοι μηχανισμοί ελέγχου είναι μεταξύ άλλων:
- code review
- αυτόματες δοκιμές
- σάρωση εξαρτήσεων
- SBOM
- παρακολούθηση ευπαθειών
- έλεγχος αδειών open source
- CI/CD με ελέγχους ασφάλειας
- διαχείριση αποθετηρίων
- τεκμηρίωση αρχιτεκτονικής
- ιχνηλάτηση της προέλευσης των components
- σαφείς κανόνες χρήσης της AI στην ανάπτυξη
Το NIST επισημαίνει επίσης τη δυνατότητα ενσωμάτωσης μηχανισμών ασφάλειας της εφοδιαστικής αλυσίδας απευθείας στα CI/CD pipelines.
Αυτή είναι μια σημαντική αλλαγή στον τρόπο σκέψης.
Η ασφάλεια δεν πρέπει να είναι ένας έλεγχος που γίνεται μόνο πριν από την ανάπτυξη.
Πρέπει να αποτελεί μέρος της διαδικασίας δημιουργίας λογισμικού.
«Ποιος έγραψε αυτόν τον κώδικα;» παύει να είναι το σωστό ερώτημα
Στον κόσμο της παραδοσιακής ανάπτυξης μπορούσαμε να ρωτάμε για τον συγγραφέα.
Στον κόσμο της AI-assisted ανάπτυξης πολύ πιο σημαντικά γίνονται τα ερωτήματα:
- Από πού προέρχεται αυτό το στοιχείο;
- Ποια άδεια χρήσης έχει;
- Ποιος το επαλήθευσε;
- Ποια έκδοση χρησιμοποιούμε;
- Ποιες εξαρτήσεις έχει;
- Συντηρείται ακόμη;
- Γνωρίζουμε τα τρωτά του σημεία;
- Μπορούμε να αναπαράγουμε το ιστορικό των αλλαγών;
- Ξέρουμε πού συμμετείχε η AI στη δημιουργία του;
Και πάνω απ’ όλα:
- Μπορεί η εταιρεία να αποδείξει ότι έχει τον έλεγχο όλων αυτών;
Γιατί ο πελάτης δεν αγοράζει, βέβαια, «κώδικα από AI». Αγοράζει ένα λειτουργικό σύστημα. Και την ευθύνη για αυτό το σύστημα εξακολουθεί να τη φέρει ο οργανισμός που το παραδίδει και το συντηρεί.
Ο κώδικας μπορεί να είναι αυτόματος. Η ευθύνη όχι
Αυτό είναι πιθανότατα μια από τις σημαντικότερες αλλαγές που φέρνει η AI στα software houses.
Ο προγραμματιστής δεν εξαφανίζεται. Ο ρόλος του αλλάζει.
Όλο και πιο συχνά το ζήτημα δεν είναι μόνο η συγγραφή ενός συγκεκριμένου αριθμού γραμμών κώδικα. Το ζήτημα είναι ο σχεδιασμός της λύσης, ο έλεγχος των παραγόμενων στοιχείων, η αξιολόγηση του ρίσκου, οι δοκιμές, η ενσωμάτωση, η ασφάλεια και η συντήρηση ολόκληρου του συστήματος.
Ομοίως, η εταιρεία δεν μπορεί να περιοριστεί στο να ρωτά αν οι προγραμματιστές της χρησιμοποιούν AI.
Πρέπει να ξέρει πώς τη χρησιμοποιούν, σε ποια διαδικασία, με ποιους ελέγχους και πώς αυτό επηρεάζει ολόκληρο τον κύκλο ζωής του λογισμικού.
Γιατί σε λίγα χρόνια το ερώτημα μπορεί να μην είναι: «Ποιος έγραψε αυτό το σύστημα;»
αλλά: «Μπορείς να αναπαράγεις από τι και με ποιον τρόπο κατασκευάστηκε;»
Αν η απάντηση είναι «όχι ακριβώς», το πρόβλημα δεν είναι η έλλειψη ενός ακόμη εργαλείου AI.
Το πρόβλημα είναι η έλλειψη ελέγχου πάνω στη software supply chain.
