As Vince already pointed out, your data design doesn't fit well within the relational model, which makes storing and querying it in a relational data store kludgy. That said, it is not uncommon to see this kind of data design, and most relational data stores and the SQL standard itself have made some accommodations.
Trying to use SQL LIKE to accomplish your matching will result in a long list of LIKE and OR statements. Depending on your backend data store, you can use expanded pattern matching through LIKE or SIMILAR. The not-so-good news is that expanded pattern matching is very implementation/product specific, so portability suffers.
If you are working with file geodatabases, see if the following works:
field_name SIMILAR TO '(A1[ ,]%|%[ ,]A1[ ,]%|%[ ,]A1)'
Looking closely at your data, the matching is made more difficult by inconsistent use of spaces. For some records, there is a space after a comma but not all the time. My SQL above assumes there may or may not be a single space or comma before or after the value you are searching.
UPDATE:
The comparable SQL to my above using basic pattern matching with LIKE is:
field_name LIKE 'A1,%' OR
field_name LIKE 'A1 %' OR
field_name LIKE '% A1 %' OR
field_name LIKE '% A1,%' OR
field_name LIKE '%,A1 %' OR
field_name LIKE '%,A1,%' OR
field_name LIKE '% A1' OR
field_name LIKE '%,A1'
The SQL code using LIKE is very portable, but as you can see, you shouldn't expect much for performance when you chaining together so many condition checks using OR.